pgw#958: the three cell-identity counters restart at v1, and ck6 is reverted

[PaulFidika]

Rebased onto master and rewritten for Paul's 2026-08-07 ruling. This PR was held by pgw#958's own step-3 sequencing; that hold is now released (see Purge below).

The ruling this executes

"The ck6 is wrong and can be removed / deleted just fine. The v1 is the correct one." — Paul, 2026-08-07

PR #512 landed ck5 → ck6 on master (88ee1709) while this branch was blocked. That bump is reverted, not carried forward, and the cells it keyed are the deletable artifacts the ruling says they are.

cell_key.KEY_SCHEME ck6→ck1, env_seal.SEAL_VERSION 6→1, guard_closure.MANIFEST_VERSION 3→1 — in one commit with every test pin that moves with them, because all three are digest inputs and splitting them means three fleet-wide re-keys instead of one. DESIGN-RULINGS §1.27(g).

pgw#990's other two decisions are deliberately KEPT

The ruling is about the counter's value, not about these, and both are load-bearing. The three test-file conflicts were resolved to preserve them:

• code_closure stays OUT of the key. Identity is the COMPUTATION; a 147-file content hash re-keyed the whole fleet for edits that cannot change a traced graph.
• is_key stays scheme-AGNOSTIC, byte-identical to tensorhub's compilecache.IsCellKey, for the reason th#1183 gives. Reverting it to the ck1-only check this branch carried before the rebase would answer every foreign-scheme cell unreadable_cell_key — a refusal on a label that no axis justifies. So: ck1 is what this runtime MINTS, while ck2..ck6 tokens stay key-SHAPED and are ruled on by axes.

The purge is DONE, not assumed

Re-issuing ck1 is only honest once the corpus that already used it is gone — the corrected census found 71 ck1 cells on the master stack and 2 on dev, minted 2026-07-21..29, so the collision this issue was filed about was already on disk. §1.27(g) requires a persisted counter be reset by migration, and the hub exposes no DELETE for cell_store at all, so this could never be a pgw action.

It is tensorhub migration 20260806T064516Z-e68cfe98 (th#1636, merged b424c1eb), and it has applied to both standing stacks — verified in public.migrations, not inferred from the merge:

stack	migration applied	cell_store	receipts	demand	revocations
master	2026-08-06 20:34:11Z	0	0	0	0
dev	2026-08-06 07:11:33Z	1 (ck5-a53e02a7…)	1	1	0

Dev's single row was re-minted 2026-08-06 14:43 by a 0.93.1 pod, after the purge. Under ck1 it can only MISS (cell_key.py:55-59 — a wrong key is never a refusal), so it is left for the cas-gc operator follow-up rather than a second migration. cell_mint_obligations is deliberately untouched: no cell_key column, no ambiguity. No bucket outside the cell prefix is touched by anything here.

Also in this sweep

aot_wrapper_split's telemetry label version="v2" → lever="runimpl" (it names which split fired and was never a version), and the ck5/ck6 numerals left in prose across aot_cells, aot_serve, aot_package, aot_flatten, graph_hash, compile_cache and the unreached-surface baseline are retired. warm_spans.py keeps its ck5-a53e02a7… verbatim — that is a quoted pod observation, not a live scheme reference.

No ordering comparison anywhere reads any of the three; the only version compare in the tree is aot_resume.BANK_V, already an equality check at 1. COZY_CELL_EPOCH remains the designed disown-everything lever, so these counters never move for recall reasons again.

Gates

Conflicted files re-run after resolution: test_cell_key.py + test_determinism_pgw694.py + test_recipe_identity.py — 47 passed. Full tests/ + tests_v2/ reported in a follow-up comment.

No version bump and no CHANGELOG.md edit — changelog.d/pgw958.md is this lane's fragment.