id(local_events): clear_tag can never clear a name with more than 256 live claims — it builds one tag.clear over the 256-claim cap and every attempt fails #1720

Problem

id claim clear can never clear a tag name once a subject carries more than 256 live claims of that name. The clear is unrecoverable through the CLI/library: every attempt fails with the same error and no claim is removed, so the tag name is stuck on that subject forever (short of hand-editing the store).

Evidence (verified this run on main 7248a166)

• pkgs/id/src/local_events.rs:213-228 — LocalEvents::clear_tag collects every live claim matching (subject, name) into one TagOp::Clear { claims } and records it as a single event. There is no chunking and no partial-clear path.
• pkgs/id/src/tag_claims.rs:36 — MAX_CLEAR_CLAIMS = 256 ("The most claims one tag.clear may name").
• pkgs/id/src/tag_claims.rs:130-138 — check_op refuses a clear naming more than 256 claims.
• pkgs/id/src/chain.rs:216 — building/signing the event runs check_op, so record() fails before ingest; the error surfaces to id claim clear (pkgs/id/src/commands/claim.rs:69).
• Nothing stops a subject accumulating >256 live claims of one name: live_claims/compacted_claims key sets by event ID (tag_claims.rs:182+), so repeated set_tag calls — by one node or by many authors sharing/syncing a store — each add a distinct live claim. No dedup by (author, name, value) exists.

Reproduction (probe in the real crate, run on the laptop)

Probe test (LocalEvents over a temp store, --no-default-features), probe + log preserved in the goal bookkeeping (probe-2026-10-28-laneB-clear256/):

• Control: set 3 claims named city on one subject → clear_tag succeeds, count = 3, 0 live claims remain.
• Bug case: set 257 claims named topic on the same subject → 257 live claims; then:

PROBE live topic claims before clear: 257
PROBE clear_tag(257) ERR: extension refused: 257 claims, the most is 256
PROBE live claims after clear attempt: 257
test result: ok. 1 passed

Why it matters

Tag clearing is the only removal path for claims (id claim clear, LocalEvents::clear_tag). A busy or contested subject — exactly the subjects most likely to need clearing (spam, a popular document, many authors setting the same tag) — crosses 256 live claims and becomes permanently unclearable. The failure gives the user no workaround and no partial progress.

Suggested direction (for triage to pin)

Have clear_tag emit as many tag.clear events as needed, each naming at most MAX_CLEAR_CLAIMS of the collected claims (each subsequent clear's causal past includes the earlier events, and a clear only needs its named claims in its own past — the claims themselves, not the prior clears). The returned count should be the total cleared; the returned event ID shape needs a small contract decision (e.g. the last clear's ID). Raising the cap instead is not a fix: the header decoder's array bound is what the cap mirrors.

Acceptance criteria

• Clearing a name with >256 live claims on a subject succeeds: all of those claims are removed (regression test at e.g. 257 and at a multi-chunk size such as 600).
• Clearing ≤256 claims still records exactly one tag.clear event and returns the same count/ID behaviour as today.
• clear_tag's return contract for the multi-event case is documented at its definition (which event ID is returned, or the shape changes deliberately).
• No live claim of the cleared name remains afterwards, and claims of other names / on other subjects are untouched.
• Existing tag/local-events tests still pass (cargo test for the id crate on laptop or CI).

Dedup

Searched open + closed issues for clear_tag, MAX_CLEAR, "256 claims", and tag-clear terms before filing: no filing covers this cap interaction. #185 ("who may clear a tag claim") is the separate policy question of clear permission, not the count cap. #1421 is a validation/mutation-testing gap for the fold, unrelated.