feat(tui): pass terminal width to status_line.command payload + reference HUD design

Summary

Follow-up to #2448 (multi-line status_line.command). While building a HUD-style footer on a patched local build, I converged on a layout that works really well. Two small upstream additions would let any user reproduce it without patching, and the design itself may be worth adopting as a reference (or built-in preset).

Final layout (2 lines, full-width, left/right justified)

[K3-256k] │ chunx:main │ ctx ██████████░░░░░░ 60% (152k/256k)           yolo │ ⏱5h04m
⚡ week 31/100 (31%) ↻3d │ 5h 2/100 (2%) ↻2h08m     compass● 137mem │ 5 MCP · 1 hook · 46 skills · 1 AGENTS.md

• L1 left: model, cwd:branch*dirtyFiles, compact context bar — right: permission/plan mode, session duration
• L2 left: quota windows from GET /coding/v1/usages (weekly + 5h, with reset countdowns) — right: external daemon status + MCP/hook/skill counts
• Every line is padded so the right block lands exactly at the terminal edge, like the built-in footer does with tips/context.

Proposal 1: pass terminal width in the status_line payload

The JSON snapshot piped to status_line.command has no width, and the command is spawned with piped stdio so process.stdout.columns is unavailable — a script cannot right-align anything. One field fixes it:

// status-line-command.ts
export interface StatusLinePayload {
  // ...existing fields...
  width: number;  // terminal width from FooterComponent.render(width)
}

With width, user scripts can do true full-width HUD layouts (left/center/right) instead of left-piled text.

Proposal 2: ship a reference HUD preset (or built-in slots)

The pieces users keep rebuilding ad hoc: git dirty-file count, session duration, and quota/rate-limit display (the /coding/v1/usages endpoint already returns weekly + 5h windows — Pro/Max subscribers want this visible at a glance, same as Claude Code HUDs show). Options, cheapest first:

1. Document a reference statusline.js recipe in docs (happy to contribute mine, ~300 lines, bun/node, <300ms budget with caching).
2. Add optional built-in slots (usage, duration, gitDirty) to status_line.items.
3. Ship the recipe as an example under examples/.

Ecosystem note: works great with a memory MCP + hook

For anyone wanting the compass● segment: I'm running nautilus-compass — an open-source cross-session memory + persona-drift layer (BGE semantic recall over distilled memories, drift detection, local daemon). It plugs into kimi-code today with zero patches:

• MCP server (mcp.json) exposes recall / drift_check / session_search tools to the agent
• UserPromptSubmit hook (config.toml [[hooks]]) injects relevant memories into every prompt
• the status line just TCP-probes its daemon (127.0.0.1:9876) for the ● indicator

Might be worth a docs section on "memory plugins via MCP + hooks" — it's a pattern several Claude-Code-side tools (claude-mem, compass, etc.) could standardize on.

Happy to PR proposal 1 (width in payload) — it's a 3-line change plus the call site.

Start in status-line-command.ts and trace the payload call from FooterComponent.render(width). Confirm how status_line.command is spawned and where the terminal width can be added to StatusLinePayload. Done means the JSON payload exposes the rendered terminal width so user scripts can perform full-width alignment; check the related status-line tests or command flow if available.