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>

skills/sync/SKILL.md

@@ -40,6 +40,7 @@ the `tea-guard` hook reads. No pin → exit with a pointer to `/tea:auth`.
 | `remote.py [--state] [--label] [--milestone] [-q TEXT]` | discovery: one line per Gitea issue to stdout, writes nothing |
 | `pull.py <key…>` or `pull.py --milestone M \| --label L \| -q TEXT` | Gitea → `tmp/issues/<id>.md`, plus `<id>.comments.md` when the thread is not empty |
 | `push.py [id…] [--update] [--dry-run]` | local → Gitea; validates first, **deletes the local file on success** and prints where it lives now |
+| `evict.py [id…] [--dry-run]` | refresh `state:` from Gitea, then evict the issues it reports closed; `origin: local` is never asked about and never removed |
 | `comment.py <id> --file F \| --body TEXT [--edit N]` | post or edit a comment, then refetch the thread |
 | `labels.py [--dry-run] [--fix]` | bootstrap the canonical `type/*` + `severity/*` set in a repo; exact names left alone, lookalikes reported, drift fixed only with `--fix` |
 | `map.py`, `_gitea.py` | the two layers the commands import — not commands |
@@ -308,6 +309,57 @@ a git repo no `ref` is sent and a warning names the issues that went up without
 one. Reading the branch is the only thing these scripts ask git for — they
 never check out, create, or write anything.
 
+## Evicting what the tracker says is closed
+
+```bash
+python3 <skill-base-dir>/scripts/evict.py --dry-run    # ask, report, change nothing
+python3 <skill-base-dir>/scripts/evict.py              # and remove them
+python3 <skill-base-dir>/scripts/evict.py old-thing    # just this one
+```
+
+Eviction itself belongs to `/tea:issue` (`issue_evict.py`) and is offline: the
+decision is `state: closed` plus an `origin:` that names a tracker, both read
+off the file. This script adds one thing in front of it — a `state:` that is not
+stale — and then calls that same decision. There is one implementation of "what
+may be evicted" and it is in the domain.
+
+Why it exists: a local `state:` is only as fresh as the last pull, so an issue
+closed in the web UI still reads `open` here and the offline command correctly
+leaves it alone. The workaround was `pull.py 11 12 13 14 15` — which writes the
+five closed files back to disk before anything can remove them.
+
+Order of operations, and it is the safety argument:
+
+1. every candidate's state is fetched — **all** of them, before anything is
+   removed;
+2. each answer must be an object carrying the number that was asked about and a
+   state the domain recognizes (`evict.confirmed_state`, the counterpart of
+   `push.confirmed_number`);
+3. only then does the eviction run.
+
+**A failed call evicts nothing** — not even the candidates whose answers had
+already arrived, and no refreshed `state:` is written back either. Stricter than
+push, which deletes as it goes, and free: evictions have no order between them,
+so there is no reason to start before every answer is in.
+
+- A **candidate** is an issue carrying a `gitea:` handle. `origin: local` has
+  none, is never asked about, and is never removed. An `origin: gitea` issue
+  whose handle is missing or unparseable cannot be verified — it is reported on
+  stderr and kept.
+- No `--repo`: the repo comes from each issue's own handle, so a store holding
+  issues from two repos is checked against both.
+- One GET per candidate. The store is a working set that push keeps small, and a
+  wrong answer here deletes a file — so each issue is asked about by its own
+  address rather than inferred from a list a `--limit` could have truncated.
+- A state that disagrees with the file is written back, so the store stops lying
+  about the issues that stay too. `--dry-run` makes no writes at all.
+- `.remote.json` is not pruned; see [How the slug comes
+  back](#how-the-slug-comes-back) — an evicted issue is exactly as findable as a
+  pushed one.
+- **`pull.py <n>` still fetches a closed issue.** A number is an address, not a
+  query. A closed issue pulled after an eviction is back on disk, and that is
+  the tracker answering the question it was asked, not a regression.
+
 ## What crosses the boundary, and what does not
 
 | domain | Gitea | note |