fix(rees): investigate a Sentry release-validation failure (9 Sentry events)

[JSONbored]

Summary

The REES release-validation step failed for one release, flagging a commit mismatch.

Evidence (Sentry)

GITTENSORY-X — Error: Sentry release validation failed (1): {"level":"error","event":"sentry_release_validation_failed","release":"gittensory-rees@4ef4a964f49ca29310b86594dbdd9bc7ac5e2681","failures":["release commits do not include expected commit 4ef4a964f49ca29310b86594db.... 9 events, first seen 2026-07-01, last seen 2026-07-04. Culprit runReleaseValidation(upload-sourcemaps).

Requirements

1. Confirm whether this was a one-off deploy-pipeline hiccup (e.g. a shallow clone / detached-HEAD timing issue during the sourcemap-upload step) or a reproducible gap in how the release-validation step resolves "expected commit."
2. Check whether this recurred after 2026-07-04 — if not, likely already resolved by an unrelated pipeline change; document the finding either way rather than assuming it's still broken.

Deliverables

• Root-cause finding, documented in the issue.
• A fix only if it's confirmed to still be reproducible; otherwise close with the finding recorded.

[linear-code]

JSO-3622

[JSONbored]

Already fixed — two commits, both already deployed:

1. #2976 `fix(ci): retry-poll Sentry release validation in the Orb release pipeline` (merged 2026-07-04T08:21:42Z) — added the `runReleaseValidation` retry loop (`REES_SENTRY_VALIDATE_ATTEMPTS`/`REES_SENTRY_VALIDATE_RETRY_DELAY_MS`) to absorb Sentry's own commit-association propagation lag after `set-commits`.
2. #3431 `fix(rees): gate the expected-commit check on SENTRY_REQUIRE_COMMITS` (merged 2026-07-05T07:30:56Z) — this is the real fix, and matches Seer's own root-cause read on this issue exactly: `upload-sourcemaps.ts`'s non-strict deploy path (`strict: false`, confirmed in this issue's own event tags) was passing the commit SHA into `runReleaseValidation` regardless of strictness, so `validate-sentry-release.mjs` still checked for an exact commit match even on deploys that never intended to require one — a genuine, reproducible gap (not a timing hiccup), now fixed by gating the check on `SENTRY_REQUIRE_COMMITS`.

Verified rather than assumed: `git merge-base --is-ancestor` confirms this issue's last-occurrence release commit (`4ef4a964f4...`, deployed 2026-07-04T05:49:07Z per the event's own `app_start_time`) predates both fixes — it's the last PRE-fix occurrence, not a recurrence. Zero events since. Test coverage already exists and specifically pins this exact regression: `review-enrichment/test/sentry-release-validation.test.ts` — "does NOT enforce the expected-commit match when SENTRY_REQUIRE_COMMITS=false" and "never calls the commits endpoint at all when SENTRY_REQUIRE_COMMITS=false, even if that endpoint is unhealthy."

No code change needed.