feat(scripts): add review-bounty claim saturation checks (#797)

Author: yanyishuai

docs/admin-runbook.md

@@ -352,9 +352,15 @@ the reviewer login:
 python scripts/review_bounty_candidates.py \
   --repo ramimbo/mergework \
   --reviewer reviewer-login \
+  --bounty-issue 654 \
   --format markdown
 ```
 
+When `--bounty-issue` is supplied in live mode, the report also ingests that
+issue's claim comments and classifies duplicate/stale claim risk (`already_claimed_on_bounty_issue`,
+`already_claimed_current_head`, `claimed_by_pr_comment`, `claimed_stale_head_or_base`,
+`dirty_unclaimed_current_base_candidate`) with matched claim URLs for auditability.
+
 The report classifies open PRs as fresh review candidates, self-authored,
 already reviewed at the current head by that reviewer, already covered by
 current-head human reviews, waiting for author update, dirty/conflicted, missing
@@ -438,6 +444,28 @@ balances. Keep the legacy callback
 links still need it. If the GitHub app is rotated later, update deployment
 secrets outside the repository and restart Docker Compose.
 
+After deploy or when bounty comments look stale, run the public link health
+check against representative bounty, proposal, proof, and OAuth URLs:
+
+```bash
+python scripts/check_public_mrwk_links.py --input fixtures/public_mrwk_links.json --fail-on-issues
+```
+
+The script fails when a published link returns HTTP 4xx/5xx or an Express
+`Cannot GET` shell instead of the expected public detail response. OAuth routes
+use a separate health rule: `422` or `503` from FastAPI means the route is
+registered, while `404` or an Express shell means production is serving the
+wrong app (see issue #1146).
+
+Post-deploy, also run:
+
+```bash
+docker compose run --rm app python scripts/check_deploy_ready.py
+```
+
+That gate now verifies GitHub OAuth login/callback routes are registered in
+the built app before a release goes live.
+
 ## Disputes
 
 - Ask for concrete missing evidence with `mrwk:needs-info`.