BE-018 MED: hunk-body tok32 end field wraps at 16 MiB — large-file views corrupt silently

Views that build one big hunk let the tok32 END offset (a 24-bit field) wrap at 16 MiB with no guard:

views/log/log.js:46 — log builds ONE unbounded hunk; past 16 MiB of body the tok ends wrap.
views/why/why.js:166 — buildBody sizes the body at 64 MiB but the same 24-bit end wraps at 16 MiB, so blame spans / O-targets corrupt on large files.

From the 2026-07-07 be/ review (BE/REVIEW), both CONFIRMED. Method Issues.

Input

Context

tok32's end offset is 24-bit (16 MiB ceiling); a body larger than that produces silently-wrapped token boundaries — wrong spans, not a crash.
why.js's 64 MiB body allocation is itself a tell that the author expected >16 MiB inputs the tok can't address.

Goals

A body approaching 16 MiB either splits into multiple hunks or refuses with a code; token ends never wrap silently.

Constraints

Repro-first (a >16 MiB file/log → correct spans or loud refusal); reuse the hunk-chunking contract other views use if one exists.

WIP

Design decisions

(pending — chunk vs refuse)

TODOs

Repro: >16 MiB body renders correct spans (or refuses).
Guard/chunk the tok end; suite green.

Blockers and bummers

None known.

Outcome

(pending)