layout reader ctx

[onursatici]

Summary

Introduce LayoutReaderContext, a typed-data registry threaded through reader construction so an ancestor layout can publish values that descendant layouts look up by type at construction time.

Breaking: Layout::new_reader and VTable::new_reader gain a &LayoutReaderContext parameter. Out-of-tree impls will get a compile error and must add it

[codspeed-hq]

Merging this PR will degrade performance by 16.59%

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

❌ 1 regressed benchmark
✅ 1236 untouched benchmarks

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	chunked_varbinview_opt_canonical_into[(1000, 10)]	187.7 µs	225.1 µs	-16.59%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing os/layout-overrides (e8f8e0d) with develop (008c1d9)}

[joseph-isaacs]

No TypeId please

[onursatici]

would that import bug that hit our use of type id be relevant for this type of use as well? I can use the layout id here, I think it is a bit of a weirder api to have but should work

[joseph-isaacs]

Can we use a Array like Id instead of a TypeId

[gatesn]

What's wrong with TypeId? We use this structure for all ephemeral context objects, i.e. VortexSession.

It works correctly, is very fast, and helps keep it clear that this stuff is never serialized.

The general Id is more used for things that are serialized and then later looked up in a registry on the other end.