refactor(lstar): freeze the Block family

[alexanderlhicks]

What

Set frozen=True on the last mutable containers in the lstar object graph apart from State and Store:

• BlockBody, BlockHeader, Block, SignedBlock (containers/block.py)

After this, every consensus container except the State accumulator and the fork-choice Store is immutable.

Stacked on #842. This PR builds on the constructed-once freeze; until #842 merges, the diff here also shows #842's commit. Review only the second commit (refactor(lstar): freeze the Block family), or merge #842 first.

Why

These four were deferred from #842 because each was patched in place after construction. Closer review showed those mutations are not blocked by the future State refactor — every site migrates cleanly to model_copy(update=...), which is byte-identical in hash_tree_root. Freezing closes the last accidental-mutation gap on the block object graph, which matters because a Block / Checkpoint is routinely shared by reference across fork choice, the chain, and attestations.

Migrated mutation sites

Production (src/):

• block_production.py — build with a zero state root, process, then rebuild the block with the real root.
• state_transition.py — rebuild the latest header with its cached state root and reassign it on the still-mutable State, instead of mutating the header in place.

Test framework + tests: the block builders, the signature-tampering helpers (verify_signatures.py), and the block-production unit tests now rebuild blocks and bodies through layered model_copy, matching the pattern the attestation-swap tamper already used.

Deferred

State and Store stay mutable. State is the copy.deepcopy + in-place accumulator at the heart of the state transition; converting it to return a new value is a larger, separate change. Store is fork-choice scratch state.

Caveat

frozen is an enforcement aid, not a hard immutability guarantee (model_config is a mutable dict; pydantic#12361).

Tests

Adds immutability tests for the four containers in the source-mirrored path (new test_block.py), following the established idiom.

Validation

• ruff (lint + format), ty, codespell — clean
• Full unit suite: 3139 passed, 92.77% coverage
• uv run fill --fork=lstar --clean: 520 passed, vectors regenerate cleanly (every migration preserves hash_tree_root, so fixtures are byte-identical)

🤖 Generated with Claude Code

[tcoratger]

After a discussion with @JustinDrake, I removed most of them here #789 to improve readability because this is pretty verbose and because we thought that formal verification may be far away. But now that you have a look at it, very happy to put them back if this can help you in the future.

I even think that to avoid

model_config = Container.model_config | {"frozen": True}

everywhere, we can enforce it directly here

leanSpec/src/lean_spec/base.py

Lines 48 to 60 in 7ed65b1

	class StrictBaseModel(CamelModel):
	"""Strict base model for all spec types.
	Adds two constraints on top of CamelModel:
	- Extra forbidden: unknown fields rejected at construction
	- Strict: no implicit type coercion
	"""
	model_config = CamelModel.model_config | {
	"extra": "forbid",
	"strict": True,
	}

so that all of our classes will inherit but let's do that in a followup!

[alexanderlhicks]

Thanks, this is useful context since I started looking at this after 789, My sense was that it would be good to have this where possible and that it would be more disruptive to do it later.

I even think that to avoid

model_config = Container.model_config | {"frozen": True}

everywhere, we can enforce it directly here

leanSpec/src/lean_spec/base.py

Lines 48 to 60 in 7ed65b1
class StrictBaseModel(CamelModel):
"""Strict base model for all spec types.

 Adds two constraints on top of CamelModel: 

 - Extra forbidden: unknown fields rejected at construction 
 - Strict: no implicit type coercion 
 """ 

 model_config = CamelModel.model_config | { 
     "extra": "forbid", 
     "strict": True, 
 } 

so that all of our classes will inherit but let's do that in a followup!

Yep this would be worth looking into. I think if we agree that we should aim for things to be immutable (and as the caveat in the PR body says, the solution in this PR is really a bandaid around a mutable structure) then we can focus on retaining legibility.
Immutability can be useful for the sake of testing and, in due course, bridging to verification tools, but with respect to guiding implementations it will likely be a implementation decision for the dev rather than something which is enforced so we can afford to make the spec more legible even if immutability is not as obvious?