Add automated GHA release workflow (WT-1042)

Replaces the current manual 12-step release process with a single
workflow_dispatch-triggered GitHub Actions pipeline that handles the
full deployment cycle from preflight checks through to production.

## What the workflow does

The workflow (`.github/workflows/release.yml`) runs five jobs in sequence:

1. **preflight-checks** — Resolves the HEAD SHA of main, posts a
   "Starting release" message to #www and #www-notify with a count of
   pending commits, then gates on four CI signals for that exact SHA:
   unit tests, pre-commit standards, Docker image build (dev), and at
   least one integration test run for main/dev. All checks poll the GHA
   API rather than re-running tests themselves.

2. **deploy-to-stage** — Verifies HEAD still matches the release SHA
   (guards against a concurrent push to main), posts "Pushing to Bedrock
   stage" to #www, then pushes the SHA to the `stage` branch. Waits for
   the `build-and-push` workflow to complete for that commit on stage,
   then waits for both integration test runs dispatched by the deployment
   infrastructure to succeed. If `pause_on_staging=true` was requested,
   also posts an approval prompt to #www with a link to the workflow run.

3. **prod-approval-gate** — Only runs when `pause_on_staging=true`.
   References the `prod` GitHub environment, which should have required
   reviewers configured; the workflow pauses here until a reviewer
   approves in the GHA UI.

4. **deploy-to-prod** — Verifies HEAD again, then runs
   `bin/tag-release.sh --ci --push` to create a `YYYY-MM-DD[.X]` tag
   and push it along with HEAD to the `prod` branch. Posts "Pushing
   Bedrock Prod, tagged X" to #www, then waits for the prod Docker build
   and both prod integration test runs to succeed.

5. **notify-completion** — Always runs regardless of earlier job
   outcomes; posts a final success or failure summary to both #www and
   #www-notify. Distinguishes the case where the tag was pushed but
   post-deployment checks failed (partial completion).

## Changes to bin/tag-release.sh

Adds a `--ci` / `-c` flag for non-interactive use:
- If main and stage branches do not match, exits non-zero with a clear
  error message instead of prompting for "Override".
- Skips the "Did tests pass on staging?" confirmation prompt (the
  workflow has already verified this via the GHA API).
- Writes `tag=YYYY-MM-DD[.X]` to `$GITHUB_OUTPUT` when that env var is
  present, so the workflow can capture and report the tag name.

Interactive mode (default, no `--ci`) is unchanged.

## Security

- Workflow-level permissions are `contents: read` + `actions: read`;
  only the two deployment jobs that push branches/tags elevate to
  `contents: write`.
- All `${{ }}` expressions used in `run:` steps are passed via `env:`
  to avoid shell injection.
- `actions/checkout` is pinned to a specific commit SHA.
- `persist-credentials: false` is set on read-only checkouts;
  deployment checkouts retain credentials (needed for git push) with
  Zizmor ignore annotations explaining why.
- A workflow-level `concurrency: release` group prevents overlapping
  release runs.
- Checked with `zizmor --pedantic`: 0 findings (2 intentional ignores
  for push checkouts that require credential persistence).

## Environment configuration required

The `prod` GitHub environment should have required reviewers added
(teams: bedrock-codeowners-backend and bedrock-codeowners-frontend)
to activate the `pause_on_staging` approval gate.

Author: stevejalim