fix(tui): enable extended keys in Alacritty

[valda]

Summary

• recognize Alacritty as an extended-key-capable terminal in the Ink TUI
• request Kitty keyboard protocol / modifyOtherKeys reporting there
• cover Alacritty capability detection while keeping unknown terminals disabled

Depends on #88957. Enabling extended keys makes Alacritty report Ctrl+J as a normalized modified key; #88957 preserves its documented newline behavior.

Root cause

Alacritty 0.16 implements the Kitty keyboard protocol, but Hermes omitted it from EXTENDED_KEYS_TERMINALS. As a result, Hermes did not request distinct modified-key reporting, and Shift+Return could collapse to ordinary Return.

No existing open PR adds Alacritty to the Ink TUI extended-key allowlist. Related CLI protocol work such as #87630 changes the classic Python CLI, not @hermes/ink.

Behavior

Alacritty now receives the same extended-key activation as Kitty, WezTerm, Ghostty, and the other existing allowlisted terminals. Unknown terminals remain opt-out.

This should land after #88957: enabling extended keys causes Alacritty to report Ctrl+J as a normalized modified key, which that PR maps to the documented newline behavior.

Testing

• npm test --workspace ui-tui -- --run packages/hermes-ink/src/ink/terminal.test.ts (9 passed)
• npm run typecheck --workspace ui-tui
• npm run lint --workspace ui-tui (0 errors; 2 pre-existing warnings)
• npx prettier --check ui-tui/packages/hermes-ink/src/ink/terminal.ts ui-tui/packages/hermes-ink/src/ink/terminal.test.ts
• npm run build --workspace ui-tui
• git diff --check upstream/main...HEAD

Dogfood

Verified on Alacritty 0.16.1: after extended-key activation, Shift+Return is distinguishable and inserts a newline. With the companion Ctrl+J patch applied, Ctrl+J also inserts a newline and normal Return still submits.

[Enough1122]

AI code review — automated review for reference; please use your judgment.

Correct allowlist addition — Alacritty implements both the Kitty keyboard protocol and modifyOtherKeys — and threading an optional terminal parameter into supportsExtendedKeys is the right testability move without touching callers. Points:

1. ui-tui/.../terminal.ts:~321 — matching is case-sensitive exact against env.terminal. Alacritty identifies itself via TERM=alacritty (lowercase) rather than a TERM_PROGRAM value in most setups, while the list also contains mixed-case entries like iTerm.app. Please confirm which environment variable env.terminal actually reads and that its real-world casing for each listed terminal matches these strings exactly — otherwise the new entry (and possibly others) never matches in practice. A case-insensitive comparison would make the whole list robust.
2. The new test covers the true/false branches of the function itself; consider one integration assertion that the extended-keys init sequence is actually written when running under an Alacritty-like env, since allowlist membership alone doesn't prove the flag reaches the terminal setup path. (nit)

No blocking issues found beyond confirming item 1's variable/casing reality.