Phase 1.1: dialog input buffer growth (256-byte regression vs linenoise)

[jsavin]

Problem

BOXEN_UI_BUF_MAX = 256 in frontier-cli/boxen_ui.c:54 is a fixed cap on dialog input. The legacy read_line_with_editing in dialog_prompts.c:64-128 starts at 128 and grows via realloc unbounded.

Long paths (Jump targets), URLs, passphrases, table addresses routinely exceed 256 bytes. Past the cap, insert_char (boxen_ui.c:197) silently drops the keystroke — no feedback. Default values exceeding 256 bytes are truncated at boxen_ui.c:395-402 without warning.

This is a behavioral regression vs the linenoise path.

Fix

Make the input buffer grow on demand:

typedef struct {
    /* ... */
    char  *buf;          // heap-allocated, grows via realloc
    int    cap;          // current capacity
    int    len;
    int    cursor;
    /* ... */
} ui_ctx_t;

Initial capacity 256 (matches today's behavior for short input). Grow by doubling when insert_char would overflow. Cap at some sensible upper bound (8 KB? 64 KB?) to prevent runaway allocations from a stuck-key. On hit-cap, beep + drop (visible feedback rather than silent drop).

run_input allocates, the modal closes path frees, the return-strdup-then-free pattern stays unchanged.

Context

• Identified by /gate review of feat(repl): C.0.7g boxen<->UserTalk UI bridge Phase 1 (input prompts) #793 (Phase 1 UI bridge), 2026-06-23
• Deferred from feat(repl): C.0.7g boxen<->UserTalk UI bridge Phase 1 (input prompts) #793 — substantial enough to want its own scope
• Part of: planning/phase_c/BOXEN_USERTALK_UI_BRIDGE.md (listed as "Phase 1.1 follow-up")
• Particularly concerning for dialog.getPassword (passphrase policy hazard)

Acceptance

• Typing past 256 chars in any bridge modal works (no silent drop)
• Default values longer than 256 chars are accepted (or visibly trimmed with feedback)
• Test in tools/tui-tests/tests/test_06_ui_bridge.py exercises a >256-char input
• No memory leak when modal cancels mid-grow