Decide staged-issue fate when the post-linking spec sweep fails #655

Finding

The Spec review of PR #654 (issue-648, "Sweep spec publish session for unlinked public issues") notes that when the new post-linking sweep fires — a public issue appears in the publishing session window that is neither the staged spec nor one of its Tickets — the run closes the leak and fails, but the already-created staged spec and its Tickets stay open: needs-triage top issue, ready-for-agent Tickets, linked but undispatched.

Evidence

• Post-linking sweep: src/security/fixing.rs, end of publish_staged_spec (the unlinked_issues / fail_on_side_effects block added by Sweep spec publish session for unlinked public issues #648).
• Pre-creation sweep in the same file closes leaks before anything is created, and the suite pins that atomicity down ("a rejected staged spec must not create a public issue", tests/security_run.rs). The post-linking path has the opposite atomicity: staged issues exist when it fails.
• The orphaned issues are inert (validated-safe text; the top is needs-triage and the Tickets are sub-issues, so no Pickup run takes them), and the failure message tells the Day shift what happened — but nothing records whether that is the intended end state.

Why this is not the agent's call

Issue #648 says only to "fail or close them" — the unlinked leaks. It does not say what should happen to the already-created staged spec and Tickets on that failure path: leave them for triage, or close them too. Closing validated work the spec does not ask to destroy would be inventing behavior; keeping the current leave-open behavior bakes in an end state the spec never chose. That is a Spec / Day-shift decision.