fix(scrollback-trim): keep the full tail when the cut lands on a line boundary

[dormouse-bot]

Nightly survey finding on lib/src/lib/scrollback-trim.ts.

When persisted scrollback exceeds the cap, trimPersistedScrollback keeps the last maxChars characters and then cuts forward to the next newline so replay never shows a torn partial first line. But when the maxChars-char tail already begins exactly on a line boundary (the character just before it is \n), there is no torn first line — the tail is already a clean set of whole lines that fills the cap exactly. The old code still searched for the next newline and dropped that first full line, trimming one line more than necessary.

Example: trimPersistedScrollback('aaaa\nbbbb\ncccc\n', 10) returned 'cccc\n' even though the clean 10-char tail 'bbbb\ncccc\n' fits within the cap. The fix returns the whole tail when it starts on a boundary.

The output was always valid (trailing \n preserved, no torn line), so this is a quality fix, not a crash — it just retains slightly more useful scrollback on restore, which matches the module's stated intent ("the top of the buffer is the least useful thing to keep when we have to drop something"). Never exceeds the cap, since the retained tail is exactly maxChars.

Behavior in the spec (docs/specs/transport.md, "Persisted scrollback cap") is unchanged: still capped, still cut at a line boundary, still keeps the tail. Added a regression test (keeps the whole tail when the cut already lands on a line boundary) that fails on the old code and passes now.

[cloudflare-workers-and-pages]

Deploying mouseterm with    Cloudflare Pages

Latest commit:	01a2dc9
Status:	✅  Deploy successful!
Preview URL:	https://e9ffa68f.mouseterm.pages.dev
Branch Preview URL:	https://nightly-scrollback-trim-clea.mouseterm.pages.dev

View logs