Sentry Integration: Track staging commits #1241

Describe the current behavior
Staging deploys on every green main CI run through .github/workflows/deploy-staging.yml (SSM → EC2 → docker compose -f docker-compose.staging.yml). The commit sha is already passed as the GIT_SHA build arg, but the Sentry release id ignores it, so every staging event in the kaapi-staging project reports the same release. Many changes land on staging between production releases, and there is no way to tell which merge introduced a staging issue.

Describe the enhancement you'd like
Depends on the shared release-id code from the production issue (kaapi-backend@<RELEASE_TAG or API_VERSION>+<git sha 12>).

• docker-compose.staging.yml: pass RELEASE_TAG as a build arg next to GIT_SHA for every service that builds the backend image.
• deploy-staging.yml:
  • set RELEASE_TAG=main alongside GIT_SHA=$DEPLOY_SHA in the docker compose build command
  • checkout the repo with fetch-depth: 0 in a step after the SSM command succeeds
  • register the release and deploy with getsentry/action-release (release: kaapi-backend@main+<DEPLOY_SHA 12>, environment: staging, set_commits: auto) only when the SSM deploy succeeded
• GitHub setup: reuse the SENTRY_AUTH_TOKEN secret and SENTRY_ORG variable; add SENTRY_STAGING_PROJECT = kaapi-staging.

Why is this enhancement needed?
Each staging deploy becomes a Sentry release with its commits, so a new staging issue points at the merge that caused it before the change reaches production.

Additional context

• Use DEPLOY_SHA (workflow_run.head_sha), not github.sha: this workflow is triggered by workflow_run, where github.sha is the default-branch head, not necessarily the deployed commit.
• deploy-staging-ecs.yml (manual workflow_dispatch) is a second staging path; decide whether it stays and, if so, apply the same steps there.
• Verify after the next main merge: Sentry → Releases in kaapi-staging shows kaapi-backend@main+<sha> under staging with commits attached.