fix(ci): no-op jobs emit same check-run name as their real counterparts

[HongmingWang-Rabbit]

Summary

Closes the auto-promote-staging deadlock at a deeper level. Branch protection on `main` requires "E2E API Smoke Test" as a status check. Design B split each gate workflow into `detect-changes` + `no-op` + real-job paths. When paths don't match:

• Real `e2e-api` job (`name: E2E API Smoke Test`): SKIPPED
• No-op job (default name `no-op`): SUCCESS

Branch protection counts the skipped check-run as not-satisfied → auto-promote-staging's FF push to main rejected with GH006.

Observed incident

2026-04-29 00:22 UTC, force-dispatched auto-promote-staging on staging tip 3f99fed after gates were all green:

```
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: - Required status checks "..., E2E API Smoke Test, ..." were not set
by the expected GitHub apps.
```

Every gate green at the workflow-conclusion level, but the per-check-run name didn't match what branch protection required.

Fix

Give the no-op job the same `name:` as the real job. With:

```yaml
no-op:
if: needs.detect-changes.outputs.api != 'true'
name: E2E API Smoke Test
...
e2e-api:
if: needs.detect-changes.outputs.api == 'true'
name: E2E API Smoke Test
...
```

Both jobs register as check-runs named "E2E API Smoke Test". Exactly one runs per workflow execution (mutex `if`). The other registers as skipped with the same name. Branch protection sees at least one success, requirement satisfied.

Applied symmetrically to e2e-staging-canvas.yml's no-op (`name: Canvas tabs E2E`) so the next required-checks reshuffle doesn't recreate this bug.

Why Design B got it half-right

Design B's intent was "emit a result auto-promote can read" — that worked at the workflow-conclusion level. This PR closes the second-order gap: emit a result branch protection can also read.

Test plan

• PR's CI passes
• After merge, dispatch auto-promote-staging force=true → FF push to main succeeds
• main advances to current staging tip