ci(release): validate Sentry releases after deploy

[JSONbored]

Part of #998. Related: #1469, #1726, and #1730.

Context

The REES source-map path now works, but the CA certificate failure showed a gap: CI/build validation can pass while runtime upload fails after deploy. Maintainer release/deploy workflows should verify that the deployed release exists in Sentry and that source maps/artifact bundles were accepted.

This must stay maintainer-only and must not add contributor-required commands or PR churn.

Requirements

• Add post-deploy validation for Sentry release/source-map health in maintainer-owned release or deployment workflows only.
• Verify the exact deployed release id, not a guessed or latest release.
• For REES, validate gittensory-rees@<deployed commit sha> after Railway deploy.
• For self-host official images, validate gittensory-selfhost@<version> during official release/image workflows.
• Verify release creation, commit association, source-map/artifact upload, deploy association, and finalized release where applicable.
• Keep source maps private; never expose maps through the app/container.
• Do not print tokens, DSNs, signed URLs, or raw environment dumps in logs.

Deliverables

• A reusable validation script or workflow step for Sentry release/source-map checks.
• Railway/REES deploy validation path that fails or alerts when upload did not happen.
• Self-host release validation path for official images.
• Tests for release-id resolution and failure handling where practical.
• Documentation for manual verification and troubleshooting.

Acceptance criteria

• A deployed REES build can be verified against the exact Sentry release id from the deployed Railway commit.
• A missing artifact bundle, missing commit association, or upload failure is visible immediately after deploy.
• Contributors do not need to run new commands for normal PRs.