Phase 1.x: boxen guard for repl.printKeyCodes() (/R K corrupts framebuffer)

[jsavin]

Problem

repl.printKeyCodes() (frontier-cli/repl.c:3544) calls linenoisePrintKeyCodes(), which takes exclusive control of stdin in raw mode and only returns once the user presses Esc three times. In the boxen REPL it would corrupt the framebuffer (raw byte echo onto the boxen-composited terminal) AND collide with boxen's own stdin reads.

The existing guard at repl.c:3545-3548 checks g_repl_active && isatty(STDIN_FILENO) — both true under --debug-tui, so it does NOT prevent the call from running there.

Fix

Add a boxen_ui_is_active() short-circuit:

static boolean replverbhost_print_key_codes(void) {
    if (boxen_ui_is_active()) {
        repl_append_scrollback(
            "/R K (Key codes) is not available in boxen mode -- "
            "exit --debug-tui and run from the linenoise REPL.");
        return false;
    }
    if (!g_repl_active) return false;
    if (!isatty(STDIN_FILENO)) return false;
    linenoisePrintKeyCodes();
    return true;
}

The message lands in the scrollback ring via the normal stdout-capture path.

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 to keep that PR scoped to dialog verbs
• Part of: planning/phase_c/BOXEN_USERTALK_UI_BRIDGE.md

Acceptance

• /R K in --debug-tui shows the "not available in boxen mode" message in scrollback without corrupting the framebuffer
• /R K in linenoise mode still works as today (regression check)
• Test in tools/tui-tests/tests/test_06_ui_bridge.py asserts the message appears and the REPL stays alive