JCT reform-vector cache can serve stale vectors across a correct full-frame checkpoint miss

From the #545 confirm sweep (sol, cites verified on main). The lower reform-vector cache (REFORM_VECTOR_CACHE_CONTEXT_KEYS, builder ~:281; read ~:4218) deliberately strips seed and target_registry_version per the #217 design ('anything outside this set cannot change a reform's per-household estimate') — but that premise has decayed:

• Registry values now rescale non_sch_d_capital_gains before reform simulations (~builder:4999), so target_registry_version IS a reform-vector input.
• Seed controls the childcare QRF (childcare.py:294) while the JCT surface neutralizes cdcc (fiscal_target_references.json:276), so seed reaches reform vectors too.
• Only household count guards positional arrays — no selected-support identity — so a selection change with equal record count would misalign.

Consequence: even when the full-frame checkpoint correctly misses (e.g. after #545's identity fixes), the lower cache can hand back reform vectors computed on the other configuration.

Fix shape: key a canonical staged reform-input/household-identity fingerprint into the context, bump TARGET_MATERIALIZATION_CACHE_SCHEMA_VERSION, and revise the test that currently asserts reuse across seed/registry changes (test_us_fiscal_refresh_builder.py ~:7488) to assert the new invalidation instead.

Materiality: the O attempts shared seed/registry so no shipped number is known-contaminated; this is a fail-closed hardening before any run varies those knobs against a warm cache.

Start with REFORM_VECTOR_CACHE_CONTEXT_KEYS and the reform-vector cache builder around :281 and read around :4218, then inspect childcare.py:294 and fiscal_target_references.json:276 for the stated seed and registry inputs. Update the test in test_us_fiscal_refresh_builder.py around :7488 to cover invalidation across seed and registry changes; done means the lower cache cannot reuse vectors for a different canonical input or household identity.