[stage] issue sweep never writes stage/040-covered-by-pr: second annotateIssueWithClaim pass resets CoveredLabelSynthesized #14397

Observation (hivecommons/hive issue list, 2026-10-26 ~18:30Z)

Repo default branch is v5 (gh repo view --json defaultBranchRef), so base ≠ default is not a factor here. Hive-authored fix PRs already get Fixes #N retrofitted / a closing link made by EnsureIssueStagePRLink / EnsureClosingIssueLink (#11888, #12144); the non-default-base case already posts the explanatory stage comment.

Root cause (A: Fixes PR open, issue stuck at 010)

Timeline for #14372: human claim (hive/claimed-by-human, 020) → PR #14375 opened 17:35Z with Fixes #14372 → claim released 17:37Z → stage/010-actionable. The next enumeration pass (pod logs 18:18Z) did see the cover:

"msg":"suppressing issue: open external PR covers it","issue":14372,"claimed_by_pr":14375,"pr_author":"thatguywob"

but issue stage labels applied items=29 writes=4 wrote nothing for it. The sweep's input labels already "had" stage/040-covered-by-pr:

1. SyncIssuePRClaimLabels calls annotateIssueWithClaim → forge lacks 040 → adds it in-memory and marks ClaimContext.CoveredLabelSynthesized=true (the 🐛 issue stage sweep never writes stage/040-covered-by-pr: synthetic in-memory label hides the gap #13316/🐛 fix(stage): write stage/040 when the forge lacks it despite the in-memory covered label #13318 fix).
2. FilterClaimedIssues calls annotateIssueWithClaim again on the same payload → now issueHasLabel(labels, 040) is true → synthesized=false, and it replaces ClaimContext with a fresh one.
3. IssueStageInputs → forgeIssueLabels sees CoveredLabelSynthesized=false, keeps the 040 label → stagelabels.Plan says "stage already right" → no write.

So the sweep path to 040 has been dead since #13318 shipped; 040 only lands via the out-of-cycle facts (clearInProgressForPR for relay-opened hive PRs, the contribute hub's verdict settle for hub-claimed humans — which is how #14346/#14364/#14360 got theirs). A human PR opened outside the hub, or any issue whose fact write was lost (the 17:37Z release write for #14372 logged effect outcome uncertain… context deadline exceeded; the pod has restarted twice today), never converges. GitHub 502/504s + the sweep's budget (issueStageSyncTimeout) made the single pass since the restart write only 4 of 29 items, which compounds it but is not the cause.

Root cause (B: 040 label, no GitHub link)

#14360: the covering PR uses Refs #14360. Hive's claim scan grades that as a Reference-tier cover → 040 (so dispatch does not re-offer the issue while the PR is open), and SyncIssuePRClaimLabels intentionally does not create a closing link for Reference claims (a closing link would make GitHub close the issue on merge, which the author declined; #12144 even retracts hive-made ones). GitHub's linked-PR icon only renders for closing keywords, so label and icon legitimately disagree for Refs covers. Not a bug; documenting here so the mismatch is understood. #14364/#14346 do carry GitHub links.

Fix

• annotateIssueWithClaim keeps CoveredLabelSynthesized across re-annotation (synthesized = !hasLabel || prevCtx.CoveredLabelSynthesized), so the sweep plans against the forge labels and writes 040 for every cover tier (external/hive closing, branch-name, Reference) and reverts to 010 when the claim lapses (existing Uncovered path).
• Table-driven test replaying the production order (SyncIssuePRClaimLabels → FilterClaimedIssues → IssueStageInputs → sweep) per claim tier, plus an idempotency test for the annotation.