fix(cli): pending-queue preview embeds a literal newline into a single-row slot

[0xMudit]

What happened

When a queued message's first non-empty line exceeds 200 characters, its pending-bar preview contains an embedded newline inside what must be a single terminal row, and the TUI frame misaligns until the queue drains.

The chain:

• limitText (packages/cli/src/pi-transcript-format.ts:183-186) returns `${text.slice(0, maxChars)}\n... ${n} chars truncated` — note the embedded \n
• firstLinePreview (packages/cli/src/pi-transcript.ts:1506-1513) returns limitText(line, 200) raw, despite its own contract: "trimmed for a one-line preview"
• the result is placed into a single pending-bar row via fitLine (pi-transcript.ts:1493, :1497)

Each element returned by a layout component must be exactly one terminal row; the viewport math counts pending-bar lines for its frame accounting. fitLine cannot catch this because pi-tui's visibleWidth treats control characters as zero-width, and pi-tui writes each array element between explicit \r\n separators — so the embedded \n physically shifts every subsequent row down one line while the diff accounting still believes one row was written. The corruption persists frame-to-frame until the queued message is consumed.

Sibling call sites already defend against this: pi-transcript-tools.ts:98 wraps the same limitText output in collapseToSingleLine(...). firstLinePreview is the path that forgot.

How to reproduce

1. Open maka in a terminal of roughly ≥210 columns (narrower terminals truncate before the newline lands)
2. During a turn, steer with a single-line message longer than 200 characters
3. On the next render, the editor/status block drops one physical row; misalignment persists until the queue drains

Suggested fix

return collapseToSingleLine(limitText(line, 200)); in firstLinePreview (or truncate by display width with '…' here instead of limitText's multiline suffix). Defense-in-depth: strip \r?\n from composed lines in the layout component's render.

[Sma1lboy]

I can take this.

Dev design: wrap the limitText result in collapseToSingleLine inside firstLinePreview, matching what pi-transcript-tools.ts:98 already does with the same output. The pending-bar contract is one array element per terminal row; limitText puts its truncation suffix behind a newline, so the preview breaks that contract whenever the 200-char cap trips.

Scope / non-goals: no change to limitText itself (its multiline suffix is correct for the block contexts that use it), no change to the layout component, and no change to the 200-char cap.

Test plan / acceptance: add a RED regression asserting no pending-queue row contains \r or \n for a queued message over the cap, and that the truncation notice still reaches the user on the same row. After the fix, renderMakaPiPendingQueue must return only single-row elements at every width.

Reproduction notes from working on this locally, in case they save you time:

• The newline survives fitLine only at widths 211–320 in my scan; below 211 fitLine truncates before the newline lands, which is why narrow terminals never show it. Row-accounting drift is 0 at width 210 and +1 at 211.
• visibleWidth reports 232 for the composed line because it counts the newline as zero-width — that is why fitLine cannot defend against this on its own.
• Captured live in a 240×20 tmux pane against the real MakaPiLayoutComponent and pi-tui renderer: the queued message occupies rows 16 and 17, i.e. one array element spanning two physical rows.

One thing I could not confirm: the issue notes the misalignment persists frame to frame until the queue drains. I have the row-count mismatch on screen and the code path (pi-tui-layout.ts:174 sizes the viewport from pendingLines.length), but I did not reproduce accumulating drift across incremental renders — pi-tui full-redraws each frame in my harness, which self-heals. Flagging it so the claim in the PR stays within what I actually observed.