messages: a fixed log of what the rows said, and a word to read it back

A message row is cleared by the next keystroke, so anything reported while you
were looking at another pane was gone before you could read it — a save that
failed, a watcher's reload, a builtin's complaint. `setMessage` now records
into a fixed ring first: no allocation and no failure path, because it sits
underneath `reportError`, which is reached from sites that are reporting an
allocation failure. `Messages` (`SPC h m`) reads it back oldest-first.

Three things an adversarial pass found, each of which defeated the feature:

PROGRESS IS NOT A MESSAGE. A language server emits `Indexing 47%` several
times a second, and every tick is a distinct string BY CONSTRUCTION, so no
de-duplication can collapse it: at the client's one-per-150ms throttle it
takes about nineteen seconds to push every real message out of the ring. A log
that one indexing run empties is not a log. That path is `setStatus` now —
the row, and nothing else.

THE CLOCK MADE EVERY HOST MESSAGE UNIQUE. `message.stamp` prefixes `HH:MM:SS`,
so `saved /x.zig` at 14:32:07 and at :09 compared unequal and the ring filled
with rows that look identical and each say (x1) — exactly the case the
de-duplication exists for. It compares `message.body` now, the row without its
clock, and the newest wording wins so the row carries the last time it
happened rather than the first. It also keys on the PANE (one pane's failure
must not be recorded as another's) and compares the truncated form, so two
identical messages over 256 bytes stop being two rows.

AND THE CAPACITY BELONGS IN limits.zig. 128 entries is 32.75 KiB that is
allocated whether or not anybody reads it — 8.5% of the ESP32-P4's whole
384 KiB heap, about the size of its effect ring. The board takes sixteen.

The builtins/leader goldens move because the listing gains a row, and
builtins.snap middle-clicks a SCREEN COORDINATE that Tutor moved out of; both
updated selectively and verified against a fresh run.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_016Q4RATpafkwahrovHQLKRf

1 files changed, 10 insertions, 0 deletions

diff --git a/src/limits.zig b/src/limits.zig
index 75bf5262..ee94a4f6 100644
--- a/src/limits.zig
+++ b/src/limits.zig
@@ -116,6 +116,16 @@ pub const cwd_buf_cap = if (board) 0 else 1024;
 /// deepest undo steps and nothing else — no truncation, no dropped edit.
 pub const undo_max = if (board) 16 else 256;
 
+/// How many message-row lines the session keeps for `Messages`, and one of the
+/// bigger fixed costs on `Pardes`: an entry is 262 bytes, so 128 of them is
+/// 32.75 KiB that is allocated whether or not anybody ever reads it. That is
+/// 8.5% of the board's whole 384 KiB heap and about the size of its effect
+/// ring, so the board takes sixteen — enough that a failure you looked away
+/// from is still there, which is the whole point, and not enough to matter
+/// beside the panes. This belongs here rather than in config.zig for exactly
+/// the reason the file's header gives: it is a board-shaped capacity.
+pub const message_log = if (board) 16 else 128;
+
 /// Bounds the only user-editable, schema-owned tag fragment. It IS the storage
 /// bound: `Pane.tag_tail` is `[max_tag_tail]u8`, and every writer (appendTag,
 /// tagInsert, restoreDumpTail, the acmefs `tag` file) refuses input that does