fix(redeploy-staging): tolerate e2e-* teardown race in fleet HTTP 500

[HongmingWang-Rabbit]

Symptom

`redeploy-tenants-on-staging` fails with:

```
##[error]redeploy-fleet returned HTTP 500
##[error]Process completed with exit code 1.
```

The per-tenant breakdown in the response body shows the failures are on ephemeral `e2e-*` tenants whose parent E2E run tore them down mid-redeploy — operator-facing tenants (`dryrun-98407`, `demo-prep`, etc) rolled fine in the same call.

Two recent occurrences (triage runs #7 and #9 today): runs 25247836697 and 25248307107.

Root cause

CP returns HTTP 500 + `ok:false` whenever ANY tenant in the fleet failed SSM or healthz. The downstream `Verify each staging tenant /buildinfo matches published SHA` step ALREADY distinguishes STALE-vs-UNREACHABLE for exactly this reason (per #2402); only the top-level `if HTTP_CODE != 200; exit 1` gate misclassifies the race as a real fleet failure.

Fix

Filter at the gate:

• HTTP 500 + every failed slug matches `^e2e-` → soft-warn, fall through to verify
• Any non-`e2e-*` failure → hard fail, with the failed slugs surfaced in the error message
• Non-500 HTTP → hard fail (CP-down, network, auth — none of which the e2e filter applies to)

Test

Replayed the gate against 6 synthetic CP responses:

• happy path → pass through ✓
• HTTP 500 + only e2e-* failed → soft-warn ✓
• HTTP 500 + mixed real + e2e fail → hard-fail ✓
• HTTP 502 → hard-fail ✓
• HTTP 200 + ok:false → hard-fail ✓
• HTTP 500 + all real fail → hard-fail ✓

Scope

Only `redeploy-tenants-on-staging.yml`. `redeploy-tenants-on-main.yml` is intentionally NOT touched: prod CP serves no `e2e-*` tenants, so the race can't occur there and the strict gate is the right behavior.

Test plan

• yaml + shell syntax clean
• 6-case unit replay of gate logic
• Next staging push that overlaps an active E2E run reaches verify (no more "redeploy-fleet returned HTTP 500" if the only failures are `e2e-*` slugs)