Fix /deploy computing release contents against a stale local production branch

[sebastientaggart]

Summary

Fixes /deploy Step 2 over-reporting a release's contents when the local production branch is stale.

In integration-branch mode, Step 2 computed the release range with git log {{BRANCH_PROD}}..<deploy-branch>, but Step 1 only ever syncs the deploy branch — it never fetches {{BRANCH_PROD}}. So the comparison ran against a possibly-stale local prod ref. When local prod lagged origin/{{BRANCH_PROD}}, /deploy listed already-promoted PRs and re-listed already-closed issues in the release contents and close set.

This bit us live during the v0.8.1 release: local main was frozen at v0.7.0, so /deploy reported production as "behind" and flagged five already-released, already-closed issues — a false alarm that cost an investigation cycle.

Fix

Step 2's integration-branch path now fetches {{BRANCH_PROD}} and computes the range against the freshly-fetched origin/{{BRANCH_PROD}}:

git fetch origin {{BRANCH_PROD}}
git log origin/{{BRANCH_PROD}}..<deploy-branch> --merges --pretty=format:"%s"

Plus a one-line rationale so the intent is self-documenting. Trunk mode is untouched (it already uses the tag-based <latest-tag>..HEAD range).

Test plan

• make check — passes (placeholder, permission, command-shape).
• make test — 163 passing, including all 7 TestDeployModeRendering cases (step numbering, no leftover directives, promotion PR present in multi-branch, gates once).
• All four adapter outputs regenerated.

Closes #213

[sebastientaggart]

Code review — medium effort

Scope: one-block fix to deploy.md Step 2 (integration-branch release-range computation). make check + 163 tests green, incl. all 7 TestDeployModeRendering cases.

Sensitive-area gate: considered and not triggered. The change touches /deploy but only its read-only release-reporting step — swaps a stale local {{BRANCH_PROD}} ref for a freshly-fetched origin/{{BRANCH_PROD}} in a git log, plus a git fetch. No change to deploy targets, prod config, the promotion/merge path, or any destructive operation.

Correctness: git fetch origin {{BRANCH_PROD}} + git log origin/{{BRANCH_PROD}}..<deploy-branch> correctly computes unpromoted commits against the current remote prod tip, fixing the over-report. Trunk mode is untouched (already tag-based). Command shapes are allowlist-friendly (bare single commands).

[NOTE] The TestDeployModeRendering suite asserts structure/step-numbering but doesn't pin that multi-branch mode renders the origin/-based range — a future assertion could lock the fix in. Non-blocking; the ticket scoped a wording fix, not new test coverage.

Verdict: APPROVE