ce-sweep: an acknowledged item never drains once its issue closes at the source

[mattspruiell]

When an issue that ce-sweep has already acknowledged is closed at the source between runs, which is the normal outcome when a PR merges with Fixes #<n>, no later sweep looks at it again. It stays acknowledged in state and stays in the rolling plan as an open requirement indefinitely.

Why

Three rules combine:

Phase	Rule	Effect on a closed issue already in state
Fetch	sources/github-issues.md:22 scopes the fetch to open issues	It is never fetched again
Fix verification	run.md:97 iterates only fix_pending items	An acknowledged item is skipped, and the source_gone rule at run.md:102 sits inside this loop
Plan reconciliation	plan-template.md:61 drains only closed or source_gone items	Its requirement is never removed

source_gone would be the wrong status even if the flow reached it: state-schema.md:67 defines it as a source that no longer exists, and a closed issue still exists.

Reproduction

1. Run a sweep against a GitHub Issues source so that an open issue is acknowledged and appears in the plan as a requirement.
2. Close that issue, either directly or by merging a PR whose description says Fixes #<n>.
3. Run the sweep again. The issue is not fetched, its state is still acknowledged, and its requirement is still in the plan.

This came up in a real run, not only from reading the skill text.

Expected

An item whose issue closed at the source is reconciled on the next run. It is either closed with evidence, when a merged fix can be verified, or moved to a terminal status that records the close without a verified fix. Either way it drains from the plan.

A possible direction

The connector already filters on an updatedAt cursor, and closing an issue sets updatedAt to the close time. A second fetch, for closed issues updated since the cursor and limited to ids already in state, would surface exactly these items. When GitHub records the PR that closed the issue, that PR number already passes the ref-shape check in run.md:97 and could go through the existing fix-verification path. A closed issue with no verifiable fix needs a new terminal status, because closed requires the three evidence fields and source_gone does not describe it.

Checked against main at 4fbabcd. The cited files are unchanged from the 3.28.2 release.