fix(pm): declare ISSUE_BODY_LIMIT from a measurement, in the unit the platform refuses in

The constant read 65536 with no provenance and was false in both directions
at once: bodies four times larger store fine (objectstack#6015 read
150,507 chars / 257,945 bytes byte-complete, and 72,754 chars / 125,561
bytes after compaction), while the refusal that does exist sits above it
and is SILENT -- the platform keeps the old body and answers 200.

So the boundary was bisected on a throwaway issue opened for it
(objectstack#18793, closed completed with the table as its body), 17
measurement writes on 2026-09-17 through post-stamped's exit register,
each read back byte-exact: 262,144 bytes STORED, 262,145 REFUSED. One
value, bracketed on both sides, 256 KiB exactly.

The unit was measured too, not assumed: 262,145 bytes carrying only
222,145 characters was REFUSED where a character-counted cap would have
taken it with 40,000 to spare, and the same multi-byte shape at 262,144
bytes / 222,144 characters STORED. The platform counts UTF-8 bytes.

renderMarkdown's trim counted `.length` -- UTF-16 code units -- against a
budget whose cap is in bytes, over rows that are largely CJK prose. It now
counts bodyBytes, as familyLedgerReservation and the size pins do; H6 next
door has counted bytes since it was written. MARKDOWN_BODY_BUDGET does not
move: a corrected reading is not a licence to print more, and the byte
guard only ever cuts earlier than the character one did.

Claude-Session: https://claude.ai/code/session_01Gqi43smmqjJ5sUrhfoPeKu
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude