Packer follow-ups: bit-exact mesh parity, spine-html over packed pages, last-page shrink

[firejune]

Follow-ups PR #263 deliberately left, batched here so the ledger carries them:

1. Exact bit-for-bit render parity for packed atlases. The pack is lossless and 11/13 rigs render byte-identical; the two mesh rigs differ by exactly 1 channel value on a handful of samples (float rounding: packed UVs are x/pageWidth, so fl(regionX + fl(s*width)) loses low bits once regionX > 0). The fix is sampling in region-local coordinates and adding the integer page origin to tap indices - a src/render.ts change that moves every committed reference frame by that same bit, i.e. a rule-5 integrity event to schedule deliberately, not slip in.
2. --profile spine-html over a packed atlas is currently a named CLI refusal (A06 full-page clause is the unpacked convention). The follow-up is relaxing A06 to "one part per page OR a tiling page" with its own fixtures.
3. Multi-page spill writes pageSize x pageSize for every page rather than shrinking the last; a shrink pass is cheap and saves texture memory on spilled packs.

None of these block the shipped feature; each needs its own verification when taken.

[firejune]

Landed

PR	#354
merge SHA	1168b78c687128275cf0c157df4094fa9495a643
CI	test pass, 3m4s on the PR (run); both post-merge main runs success

All three follow-ups are addressed. Two implemented, one measured and declined — the measurement says the stated fix cannot work, and the comment that proposed it was wrong about the mechanism, so src/atlas.ts's own paragraph is replaced by the measurement rather than acted on.

---

② --profile spine-html over a packed atlas — done

A06's coverage clause is now one part per page OR a tiling page: every region wholly inside the page it names, and no two regions on one page overlapping. The named CLI refusal for --pack --profile spine-html is gone. Rotation stays refused, separately.

⚠️ Relaxing A06 alone would have hollowed out A19. A packed page's own file all but always declares transparency (its gutter is transparent), so A19's page-level question is answered by the packing rather than by the art — it would have become a pass measuring nothing. A19 now asks per region over the decoded page on a shared page; the per-file path for the unpacked convention is untouched.

Four fixtures, all green:

case	reading
PK19_A_PACKED_ATLAS_GATES_GREEN_UNDER_THE_RENDERER_PROFILE	7 regions on 1 shared page: 29 assertions ran, 11 skipped, 0 failed
PK20_TWO_REGIONS_OVER_THE_SAME_TEXELS_ARE_REFUSED_BY_NAME	regions "00_stage" (2,2 480x270) and "01_plunger" (2,2 200x80) overlap on page "skeleton.png"
PK21_A_REGION_THAT_RUNS_OFF_ITS_SHARED_PAGE_IS_REFUSED_BY_NAME	region "00_stage" occupies 33,2 480x270 of page "skeleton.png", which is 512x512
PK22_AN_OPAQUE_PART_ON_A_SHARED_PAGE_IS_STILL_NAMED	the packed page itself DOES declare transparency (the gutter), and A19 named 2 of 2 opaque part(s)

M14's premise moved with the clause (a region that merely fails to cover its page is now what a pack looks like — the old mutant loaded clean, [nothing — the break loaded clean]). Re-aimed, not dropped: same region, same size, moved, so its far edge sits past the page. Derived from the atlas text, still no measured literal.

③ Last-page shrink — done, and generalised to every spilled page

Which parts share a page is still decided at the maximum (that keeps the boundary deterministic); each page is then written at the smallest power-of-two pair holding its own cells, through the same search the single-page case already used. One rule instead of a rule and an exception, which is why it covers every page rather than only the last.

Measured on gallery/portrait at --page-size 1024, both bases in the branch:

	pages	decoded RAM
before	1024x1024 @ 87.0%, 1024x1024 @ **40.4%**	8.000 MiB
after	1024x1024 @ 87.0%, 1024x**512** @ **80.9%**	6.000 MiB

First page unchanged — the assignment is untouched. PK08B uses the packer's own single-page path as the oracle (hand it one spilled page's regions alone; it must choose that page's size), red-first with the shrink disabled: skeleton2.png is 16x16 but its own regions fit 8x8.

---

① Bit-exact packed parity — MEASURED, and not reachable in src/render.ts

src/render.ts samples at u · pageWidth − 0.5, so "sample in region-local coordinates and add the integer page origin to the tap indices" can at best reach the packed coordinate with the origin taken back off. That is what was measured, across the three public fixtures and every frame of every animation:

piece kind	coordinates	differ from the loose pose	worst
region attachments	3 824	0	0
meshes	6 854	4 626	1.597e-5 texels

• The region half is already exact. regionX, the region extent and pageWidth are integers and the page is a power of two, so nothing is lost — which is why eleven of thirteen rigs are already byte-identical. The proposal's goal is met on that half with no change at all.
• The mesh half is lost inside spine-core. MeshAttachment.updateRegion computes u + regionUVs[i] · width into a Float32Array. Worked through on gallery/squash's ball, vertex 1:

loose path   fl(u32 * rw)                     197.78207302093506   == observed loose
packed uvs[i] (float32)                       0.7263497114181519
recovered    u*W - rx                         197.7821044921875    == observed packed
same region at page origin x = 0              197.78207397460938   != loose  (off by 9.5e-7)

🔬 The last line corrects this issue's diagnosis. It names fl(regionX + fl(s · width)) "once regionX > 0" as the cause. With a zero page origin the value is still wrong, so the term that does it is the f32(u · regionWidth / pageWidth) scaling, not the origin addition — and it is applied and re-stored in float32 before rigc reads the array.

⇒ No change to src/render.ts can recover information that is not in piece.uvs. The routes left are (a) re-deriving mesh page UVs from MeshAttachment.regionUVs in double precision — a second opinion about the runtime's own trim and rotation mapping, which artUvsOf exists to avoid by name — or (b) one part per page, the unpacked convention. And (a) is the wrong trade: the renderer is the yardstick check measures against because it draws what a runtime draws, and a runtime playing this atlas gets the float32 numbers. Making two rigc renders agree by disagreeing with the runtime buys nothing a gate can use.

Rendered consequence, three real rigs at --max 256, loose vs packed over every frame of every animation:

rig	meshes	channel samples differing	worst
gallery/walk	0	0 of 2 506 752	0 — byte-identical
gallery/squash	1	4 of 2 613 248	1
gallery/portrait	2	15 / 20 / 21 of 3.7 / 7.6 / 5.3 M	1

PK18 holds the boundary in both directions — 0 for regions, nonzero for meshes, asserted rather than tolerated. If the mesh count ever became 0, spine-core would have stopped storing mesh UVs in float32 and src/atlas.ts would owe the reader a different explanation of PK05's bound. Each count is the other's positive control.

Measured movement — the #301 discipline

src/render.ts is not in the diff, no reference fixture was re-rendered or committed, and docs/LADDER.md / docs/GATE.md are untouched. Verified rather than argued — the whole report, old base (fc82e5c) vs the branch, path-normalised and byte-diffed:

basis	old vs new
bench 3 --candidate bench/runs/2026-08-23-rung3-1/spine	IDENTICAL
check --candidate … --frames bench/reference/3-timing-and-spacing	IDENTICAL
bench 6 --candidate bench/runs/2026-08-23-rung6-1/spine (the mesh rung)	IDENTICAL
check --candidate … --frames bench/reference/6-arcs	IDENTICAL

The rung-3 bench --json reports are also identical apart from worktree paths. So not one gate clause figure moved, on the region rung or the mesh rung, and every per-clause figure docs/LADDER.md records still reproduces.

🔓 Basis adoption remains OPEN, and is not closed by this issue

To be explicit, because this item was filed as a rule-5 integrity event: no basis was adopted here, and none was proposed. The change that would have required an adjudication is precisely the one this PR declines, with the measurement above for why. What is now on record is that a region-only basis change is a no-op (the coordinate is already exact) and a mesh basis change is not available to src/render.ts at all. If anyone wants exact mesh parity, the adjudication they need is not "adopt a new reference basis" but "may the renderer hold its own opinion of mesh page UVs instead of the runtime's" — a different and larger question, and one the tower dispatches.

---

Verification

bun run typecheck   green
bun run lint        green
bun run selftest    green, exit 0 — 25 packer/importer controls (was 19), and every one of the
                    6 gallery example(s) compiled three times and gated green under BOTH profiles

Renders ran sequentially; top -l 1 -n 0 checked before each batch.

Unresolved — two stale doc quotes, deliberately not raced

• docs/INGEST.md:676 quotes A06's old message verbatim in a table (region "crosshair" has UVs … one part per page must cover the page exactly). That string no longer exists. INGEST is one of the four skill docs the audit in docs: the shared-rule duplication audit, with a canonical owner per rule #344 / docs: name a canonical owner for every rule the skill docs share #345 owns, so it is flagged here rather than edited.
• docs/LADDER.md:44 (B3) describes the clause as full-page and says "rigc still has no packer and no importer" — the second half was already stale before this issue, and the first half is stale now. LADDER was out of bounds for this batch by instruction.