fix(ccb): the live-schema table still pinned the three classes 2c-E moved

[cryptskii]

main is red. This fixes it.

What broke

ccb_conformance's live_schemas_match_the_registry_and_none_is_burned asserts every encodable class's live (class, schema) pair against a hardcoded table. That table still said 0x000B, 0x0033 and 0x000E were at schema 1. The schema-2 cut in #829 moved all three:

TradeIntent: (0x000b, 2) is not the registry's live pair

Why I missed it

Precisely, so it is fixable as a habit: I swept for tests that pin bytes, found none outside the conformance file, and did not sweep for tests that pin schema numbers. That is a different dependent class and I did not look for it.

The test is the registry-versus-code cross-check, and it did exactly its job.

It proves itself load-bearing, without a staged control

The mutation here was accidental and real — the code moved to schema 2 while the table did not — and CI turned this named test red on it. That is stronger evidence than a control I set up myself.

Dependent sweep, redone properly

By class name rather than by byte literal. Five test files reference the affected classes, all now green:

file	result
ccb_conformance	11/11 (this fix)
settlement_bundle_conformance	12/12
economic_dlv_settle_provenance	15/15
dlv_successor_conformance	5/5 — the one I had not run
common/indep_ccb	helper, already cut

The coverage log also shows the dsm library at 1786/0 before it aborted, so nothing in the library moved.

Worth noting for future triage: coverage stops at the first failing binary, so that run proved less than its 10-minute length suggested. Suites after ccb_conformance never executed.

Verification

make lint green; production safety checks green including TLA+.

[cryptskii]

Both of #829's failures — Rust and Coverage — have this same single root cause. Confirmed from both job logs: one failing test, live_schemas_match_the_registry_and_none_is_burned at ccb_conformance.rs:560, reported as 10 passed; 1 failed in each.

The other panics in those logs (from_poison_error, the two blake3 rejection tests, the_storage_set_nests_with_an_envelope...) are #[should_panic] tests panicking by design. Their binaries report ok.

A caveat worth stating plainly: neither job proved as much as its runtime suggests. cargo test stops at the first failing binary. The Rust job ran four — the dsm library at 1786/0, then 13, then 4, then ccb_conformance failed — and stopped there. None of dsm_sdk's integration binaries ran at all.

So this PR fixes the one confirmed failure, and the argument that nothing else broke is the dependent sweep rather than that run: five test files reference the three affected classes and all five are green locally. CI on this PR is what will actually clear the rest.