The tonemap and pixel-level assertions

Every baseline in the repository was re-blessed once at Plan 0045 Phase 3, when the composite became linear-light Rgba16Float with a tonemap at the surface boundary. Two things follow for anything that reads pixels here:

• A capture is downstream of a compressive curve. The curve is the identity below ~0.6 and rolls off above it, so a low- or mid-luminance assertion reads what it always read, and a bright one reads lower than the linear value that produced it. composite_overlap pins that a frame of stacked additive strokes rolls off instead of flattening: no channel of that fixture reaches 255. Do not read that as “255 is unreachable”. The curve is bounded strictly below 1 for every finite input, but the surface write encodes to sRGB and rounds, so f(x) crosses the last byte’s midpoint at a linear input of about 36 at the shipped knee — and attractor.toml reaches it on the hardware adapter. A suite-wide no-255 gate would fail on correct frames.
• A backdrop makes a bright pixel’s dim channels darker, and that is the curve working. The roll-off scales all three channels by f(m)/m off the brightest one, so adding a red-dominant bg_* under a magenta stroke raises m, drops the scale, and takes blue down with it — measured at up to 15 bytes on composite_bloom with every post stage off. Any assertion of the form “compositing something underneath may only add light” therefore has to be made upstream of the tonemap, on the linear composite, where it is exact; see a_backdrop_under_an_active_halo_only_ever_adds_light in core/src/render/bloom.rs (Plan 0045 Phase 4b).
• --report moved, slightly and measurably. Re-run over the library at that change: reactivity max 0.060 / mean 0.012, animation max 0.042 / mean 0.006, coverage max 0.187 / mean 0.010, distinctness max 0.12, reachability identical everywhere and every floor still passing. Read that as the scale of drift a luminance-model change produces in these columns — not as noise, and not as something to re-derive without measuring.