Archiving on close is a local side effect, so two clones disagree about what issue list -a shows

open   by a73x

Labels: backlog

[claude 2026-08-15] `issue close` moves the ref into `refs/collab/archive/issues/`, but that move is never replicated. A peer that receives the same close event through `sync` keeps the ref in the active namespace. The two clones then answer the same question differently.

Reproduced with two clones of one bare origin, alice closing and bob syncing:

```
alice$ git-collab issue close 656a46f4 --reason done && git-collab sync
alice$ git-collab issue list -a
No issues found.
alice$ git-collab refs | grep issues
issue, archived  refs/collab/archive/issues/656a46f4...

bob$ git-collab sync
bob$ git-collab issue list -a
656a46f4  closed  peer close test  (by alice)
bob$ git-collab refs | grep issues
issue  refs/collab/issues/656a46f4...
```

Two consequences:

1. **`issue list -a` is dead on the closing clone.** Its help says "Show closed issues too", but `list` reads the active namespace unless `--archived` is passed (src/issue.rs:32-42), and `close` has just moved every locally-closed issue out of it (src/issue.rs:360-363). On that clone no `-a` invocation can ever surface a closed issue; you need `-a --archived`. Patches do not behave this way — `patch list -a` shows merged and closed patches.
2. **Archive state is not a property of the issue.** It is a property of which clone ran the close, so it cannot round-trip. `state::archive_issue_ref` has exactly two callers, `close` and `reopen` (grep: nothing in sync/reconcile), so nothing converges it.

This also makes the closed set easy to mistake for empty and re-open duplicates of. `git-collab search` does cover archived issues, which is the only reason the state is reachable at all.

Worth deciding which is intended before fixing: either archiving converges as an event like any other status, or closing stops moving the ref and `--archived` becomes a genuine age/volume sweep rather than a synonym for closed.