feat: evict closed issues from the local store

The store is a working set, not an archive. Until now nothing removed a
closed issue from it: #10 put a filter on the write and said so explicitly
("existing store files are not cleaned"), and the migration was never
anybody's job. The only way out was rm past every script, followed by
rebuilding INDEX.md by hand.

issue_evict.py removes <id>.md and every sidecar under that slug for an
issue that is state: closed AND carries an origin: naming a tracker, then
rebuilds INDEX.md. --dry-run prints and writes nothing at all.

Two conditions, and the second one is the whole safety argument. An
origin: local issue IS the work — there is no other copy — so it is never
evicted, in any state, not even when named on the command line: it is
reported and kept. The only files that go are ones whose own metadata says
pull.py <n> brings them back, which is the trade push.py already makes
when it drops a file the tracker just confirmed.

The command lives in the domain layer, and the layering rule decides that
rather than convenience: state: and origin: are domain fields and the
answer is already on disk, so eviction needs no network, no login and no
tea. The domain also gains issue.slug_files — every file the store holds
under one slug, which is all_ids' "a slug has no dot in it" read the other
way round, and lets the domain remove an issue completely without learning
what a comment thread is.

skills/sync/scripts/evict.py is the bridge form, and it exists because a
local state: is only as fresh as the last pull: an issue closed in the web
UI still reads open here. It refreshes state: from Gitea, then calls
issue_evict.run — one implementation of "what may be evicted", in the
layer that owns the fields it reads. Same gate as push, one step earlier:
every candidate's state is fetched before anything is removed, each answer
must be an object carrying the number asked about and a state the domain
recognizes (confirmed_state, the counterpart of confirmed_number), and a
failed or unconfirmed call evicts nothing — not even the candidates whose
answers had already arrived, and no refreshed state: is written back
either. A candidate is an issue with a gitea: handle; origin: local has
none, is never asked about, and is never removed.

.remote.json is deliberately not pruned. It is the number -> slug ledger,
its entries are supposed to outlive the files they name, and an evicted
issue is in exactly the state a pushed one is.

AGENTS.md gains the rule the tracker side never wrote down: pull by number
fetches an issue in any state — an address is not a query. Eviction does
not revoke it, so a closed issue pulled after a cleanup is on disk again,
and that is the tracker answering what it was asked.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

AGENTS.md

@@ -60,12 +60,16 @@ If a tracker concept (issue number, login, HTTP call, label color, `sub_url`,
   - `scripts/issue_ac.py` — list the body's checkboxes; tick one by number or
     substring, changing exactly one character of the file
   - `scripts/issue_tree.py` — draw the dependency graph
+  - `scripts/issue_evict.py` — remove closed issues from the store; never an
+    `origin: local` one
   - `scripts/issue_index.py` — rebuild `tmp/issues/INDEX.md`
 - `skills/sync` — move issues between the local store and Gitea (`/tea:sync`)
   - `scripts/map.py` — md ↔ Gitea JSON, pure, no I/O; label colors live here
   - `scripts/_gitea.py` — transport: login pin, `tea api`, pagination, filters,
     label ids, the remote-id map
   - `scripts/pull.py`, `push.py`, `remote.py`, `comment.py`
+  - `scripts/evict.py` — refresh `state:` from Gitea, then hand the decision to
+    the domain's `issue_evict.run`
 - `skills/page` — a discussion's artifacts as a page tree (`/tea:page`),
   entirely offline
   - `references/pages.md` — canonical page-tree format; single source of truth
@@ -151,7 +155,29 @@ line so plain grep works without a parser.
 - `.remote.json` is therefore no longer "an index over the files": it is the
   local number → slug ledger, its entries outlive the files they name, and
   nothing prunes them. It is still recoverable — from the markers in Gitea, not
-  from the files.
+  from the files. **Eviction does not prune it either**, for the same reason a
+  push does not: an evicted issue is in exactly the state a pushed one is.
+- **A closed issue is evicted, not archived.** `issue_evict.py` removes
+  `<id>.md` and every sidecar under that slug for anything that is `state:
+  closed` **and** carries an `origin:` naming a tracker, then rebuilds
+  `INDEX.md`. `--dry-run` prints and writes nothing. **`origin: local` is never
+  evicted, in any state, not even when named on the command line** — that file
+  *is* the issue and nothing can fetch it back.
+- **Eviction lives in the domain** (`skills/issue/scripts/issue_evict.py`),
+  because its two inputs — `state:` and `origin:` — are domain fields and the
+  answer is already on disk. No network, no login, no `tea`.
+  `skills/sync/scripts/evict.py` is the bridge form: it refreshes `state:` from
+  the tracker first (a local `state:` is only as fresh as the last pull) and then
+  calls `issue_evict.run`. One implementation of "what may be evicted", in the
+  layer that owns the fields it reads. Same gate as push, one step earlier: a
+  failed or unconfirmed tracker answer evicts nothing at all.
+- **Pull by number fetches an issue in any state — a number is a number.** An
+  address is not a query: `pull.py 42` puts a closed issue on disk exactly as it
+  always has, and so does `#42`, `owner/repo#42`, or its URL. Only filter mode
+  (`--milestone`, `--label`, `-q`) leaves closed issues out. Eviction does not
+  revoke this: a closed issue pulled after a cleanup lands on disk again, and
+  that is the tracker answering what it was asked, not a regression. Evict it
+  again when you are done with it.
 - Pulling overwrites the body — a fetch, not a merge. It is also how a pushed
   issue comes back at all.
 - No drift tracking, and now nothing to track: there is no second copy to