Hotfix: drop the kernel-owned household_weight from the spine's output contract

[MaxGhenis]

Restores main to green.

Main went red on the #691/#692 cross-merge (both green independently, merged one minute apart): #691 (uk-654-retire-clean) made household weights typed frame state — the {entity}_weight column names now belong to the kernel and are absorbed off entity tables at frame construction — while #692's FRS spine spec still declared household_weight in its outputs and nonnegative_outputs. The post-stage produces check then looked for a column the constructor deliberately absorbs: test_root_stage_ignores_seed_frame_content fails on main with "Stage 'frs_spine' declared it produces 'household_weight' but the column is absent after the stage ran."

Change: remove the kernel-owned name from the spine's spec output contract (and the module mirror), with a comment and spec note stating where the weights actually live. The weights themselves are untouched — uk_national_frame builds typed household weights from the spine's legacy column, and the weights audit and terminal gates continue to validate them off-table.

Verified: the failing test now passes; full spine suite, country-spec conformance, spec-only packages, release-input coverage (manifest --check clean), and repo ruff all green locally.

cc @juaristi22 — this is the minimal restore-main fix; if #678's design wants the spine to declare weight establishment somewhere richer than the produces contract (e.g. a weights-audit arming receipt), happy to follow up separately.

🤖 Generated with Claude Code

[juaristi22]

Same diagnosis over on #703 — the E3 branch has carried the identical two-line drop as a standalone commit since yesterday (4d62545b, "Drop household_weight from the frs_spine output surface"), for exactly the reason you name: the produces check can't see a column the constructor deliberately absorbs.

No objection to this hotfix landing first — it un-reds main for every open PR in minutes, and #703 rebases over it trivially (our seam commit simply drops out). One heads-up so the fix is complete: this same merge window left a second latent break that CI can't see — the E1 adapter passes time_period= to UKSingleYearDataset, whose real constructor takes fiscal_year=; nothing hits it until a real-engine materialize call (E3's licensed build was the first). That fix rides on #703 (a2b85348) with an engine-gated construction test, and #703 is green with a full head-to-head data receipt against the incumbent posted here — so it's ready to follow straight after this.

[juaristi22]

Closing as superseded: #703 merged and main is green again. It carries this PR's exact two-line fix as a standalone commit (4d62545b, same diagnosis — the produces check looking for the kernel-absorbed column) plus the second latent break from the same merge window that CI couldn't see: the E1 adapter's UKSingleYearDataset(time_period=...) kwarg, fixed with an engine-gated construction test (a2b85348). Thanks for the fast diagnosis, Max — it independently confirmed the seam analysis, and the hotfix-first offer stood for a day before we merged the superset. Nothing from here is lost: main now contains both repairs.