MARK-002 HIGH: output cap len*8+16384 under-sizes dense-todo pages — wholesale BNOROOM

mark sizes its output buffer at len*8+16384 (MARK.cli.c:60), but a todo line expands ~12× (<ul class="todo">\n<li class="wontfix"><input type="checkbox" disabled> <del>… ≈ 96 bytes per 8 source bytes) — a legitimate 9.6KB page of todo entries fails wholesale with Error: BNOROOM exit 22, no HTML written, and one such page fails an entire directory build even without --strict. fuzz/MARK.c:22 uses the same 8× heuristic, so fuzzing never surfaces it. From the 2026-07-07 mark/ diagnostic review, orchestrator-verified by probe. Method Issues.

Input

Context

Probe (2026-07-07): # T + 1200× -[x] a\n\n (9.6KB) → Error: BNOROOM, exit 22, no output file (fresh build/bin/mark).
Worst-case expansion is the todo/wontfix entry markup; 8× covers prose but not marker-dense pages.
The fuzzer shares the heuristic (fuzz/MARK.c:22) AND swallows errors by design — the gap is structurally invisible to it.

Goals

Any legal input renders: size by worst-case expansion factor, grow the buffer, or stream/flush — one ruling; a single page must never fail a whole directory build on a sizing artifact.
Fuzz harness sizing follows the same rule so BNOROOM-class gaps become fuzzable.

Constraints

Repro-first (the dense-todo page as a test case); ABC buffer idioms (u8b/BASS), no ad-hoc realloc loops outside them.

WIP

Design decisions

(pending)

TODOs

Repro case in mark/test (dense-todo page renders, exit 0).
Fix the sizing rule; align fuzz/MARK.c; suite green.

Blockers and bummers

None known.

Outcome

(pending)