id(tag_claims): 4 property tests red since #4765 — generated clears name a claim twice and the store now refuses them #5132

Symptom

With the #4522 compile fix applied (PR #5117), the pkgs/id integration target tests/tag_claims.rs runs again and 4 property tests fail:

• test_the_regression_histories_reach_the_oracle_through_every_path
• test_each_event_names_every_event_its_author_had_seen
• test_the_compacted_fold_agrees_with_the_causal_walk
• test_the_live_set_is_the_oracle_under_any_delivery_order

All four panic at the same place:

thread panicked at tests/tag_claims.rs:82:69:
called Result::unwrap() on an Err value: Extension("a clear names a claim twice")

Root cause (evidence-linked, not yet fixed)

• Commit 2c47b7e fix(id): refuse duplicate claim IDs in tag.clear check_op (id(tag_claims): check_op accepts a tag.clear naming the same claim twice — every sibling hash-set field in a chain extension refuses duplicates #4765) made the store refuse a tag.clear event that names the same claim twice.
• The tag_claims property tests generate clear events from a small claim pool, so generated histories can name a claim twice; the test helper apply_clear_at unwraps the ingest result, so the new refusal fails the test.
• The breakage was invisible until now: the tag_claims target stopped compiling when ChainExt gained the checkpoint field (the id(chain): integration tests do not compile — ChainExt initializers missing new link field #4522 breakage), so these tests have not run on main since the two changes crossed.

The #4522 fix itself only adds checkpoint: None to the fixtures — the panic is in the clear-path validation and is unrelated to that field.

Fix direction (owner to choose)

Either the generator must dedupe the claims in a generated clear (a clear naming a claim twice is now invalid input, so generating it is a generator bug), or the helper should model the refusal explicitly. The store validation from #4765 looks intentional and should stay.

Why it matters

.#id-web runs the suite in its Nix check phase (doCheck=true), so this also blocks the laptop fleet switch; it joins the other runtime-red pkgs/id tests tracked in #5020, #5021 and #5128. #4522/PR #5117 restores compilation only.

Acceptance

• cargo test --test tag_claims in pkgs/id is green on main.