[refactor] spectra-archive-post-ic --linked-issue membership semantics (escape-hatch reliability) (follow-up from #170)

[kiki830621]

Problem

The #170 fix added an escape hatch: when detect_candidates returns an empty set, --linked-issue <N> is accepted authoritatively (membership validation skipped). But the 6-AI verify of PR #171 surfaced that the escape hatch's reliability hinges on "candidate set is empty", which is fragile in two ways:

1. Spurious candidate defeats the override (codex, verify P2): any non-empty candidate set — even a single spurious one from context-blind prose matching (e.g. a cross-reference see issue #164, or 可能 issue #46) — flips the path from escape-hatch to membership-validation, so a legitimate --linked-issue 555 gets rejected because 555 ∉ {spurious}. The word-boundary fix (PR fix: spectra-archive-post-ic linked-issue escape hatch + prose detection (#170) #171) removes substring matches (reissue/tissue) but NOT legitimate-English cross-references.
2. Timing-dependent emptiness (DA-3, codex): detect_candidates fallback 3 is git log -- <archive_dir>. From the repo cwd against a committed archive, F3 finds the archive's own commit #N, so the set is non-empty. The escape hatch only fires because, in production, spectra-archive posts the IC before committing the moved archive (F3 sees an untracked path → empty). Fixture 13 can only reproduce the empty case via /tmp-cwd isolation.

Root tension: --linked-issue's membership validation conflates two distinct use cases:

• exit-75 disambiguation re-invoke — agent must pick one of the detected candidates (validation is correct here, catches agent errors).
• user/agent authoritative override — caller knows the issue number; detection is irrelevant (validation is wrong here, rejects legitimate input).

The script can't currently tell them apart — both arrive via --linked-issue.

Also surfaced (DA-1, verify MEDIUM)

On the escape-hatch path, --linked-issue <wrong-but-existing-N> silently posts the ## Implementation Complete supersession anchor to an unrelated live issue. ^[1-9][0-9]*$ (PR #171) rejects 0/nonexistent-by-format, and a nonexistent number fails at gh issue comment, but a valid-but-wrong number mis-posts silently. Riskiest where no human reads the outcome.

Proposed directions (待 diagnose)

1. Separate the two intents — e.g. a --force-linked-issue <N> (authoritative, bypasses membership + detection entirely) vs the existing --linked-issue <N> (exit-75 disambiguation, validated against the candidate set). The agent picks the right one per context.
2. Existence checkpoint — on the authoritative path, gh issue view <N> before posting (catches nonexistent; does not catch wrong-but-existing — inherent to an explicit override).
3. Reconsider the membership contract — does fixture 09's "reject override not in single-candidate set" still make sense, or should an explicitly-passed --linked-issue always win?

Out of scope

• The [bug] spectra-archive-post-ic 漏偵 prose-only #N reference #170 core fix (escape hatch on empty + reorder + word-boundary + reject-0) is shipped in PR fix: spectra-archive-post-ic linked-issue escape hatch + prose detection (#170) #171 and resolves the reported double-failure. This is the deeper semantic design layer.

---

Source: surfaced during /idd-verify #170 --pr 171 (6-AI ensemble — codex + devil's advocate). Full report: #171 (comment). Sister concern from #170.