Phase 1.x: dialog.getInt should re-prompt on parse failure, not cancel

[jsavin]

Problem

boxen_ui_get_int in frontier-cli/boxen_ui.c:461-468 returns false (cancel) on parse failure:

char *endp = NULL;
long v = strtol(result, &endp, 10);
if (endp == result || (endp && *endp != '\0')) {
    free(result);
    return false;
}

The legacy dialog_get_int (dialog_prompts.c:155, 184) re-prompts in a loop after an invalid integer with "Invalid integer. Try again." Scripts that don't distinguish "user cancelled" from "user typo'd" misbehave under the bridge (likely abort an operation the user just wanted to fix).

Fix

In the int-mode branch of run_input (or in boxen_ui_get_int directly), on parse failure: don't return — clear ctx->buf, set a one-line hint at the modal's top ("Invalid integer; try again."), repaint, continue the mini-loop. Esc/Ctrl-C still cancel; only Enter-with-invalid triggers the re-prompt.

Context

• Identified by /gate review of feat(repl): C.0.7g boxen<->UserTalk UI bridge Phase 1 (input prompts) #793, 2026-06-23
• Already acknowledged in the bridge code comment (boxen_ui.c:464-468): "Phase 2 candidate"
• Easy now that the basic input loop works

Acceptance

• Typing abc then Enter in dialog.getInt clears the field and shows "Invalid integer; try again." (or equivalent)
• Typing a valid integer then Enter returns the value
• Esc/Ctrl-C cancel from any state, including after invalid input
• Test in test_06_ui_bridge.py exercises the invalid-then-valid path