fix: inject text for control-socket send_key so keys reach the PTY

[calebcarvalho]

Summary

send-key over the control socket is silently ignored — no key (not even a
printable character, and critically not Return) reaches the shell. This makes
socket-driven automation unusable on Linux: you can build layouts and send
text into a pane, but you can never submit a command.

Root cause

TerminalHandle::send_key builds its ghostty_input_key_s via
translate_key_event, which hard-codes:

ghostty_input_key_s {
    ...
    text: ptr::null(),
    ...
}

Ghostty relies on the text field to write the character to the PTY. Because
send_key never populates it, ghostty_surface_key receives a key event with
no text and nothing is written to the shell. key_event_text can't help here
either — it deliberately returns None for control characters, so Return
(\r) would be dropped even if it were consulted.

Repro on main:

limux send     --surface <ref> "echo hi"   # text appears at the prompt
limux send-key --surface <ref> Return       # returns OK, but nothing executes
limux read-screen --surface <ref>           # command still sitting at the prompt, unexecuted

Fix

Populate press.text in send_key from a small helper that maps the common
control keys to their PTY bytes (Return/KP_Enter → \r, Tab → \t,
Escape → \x1b, BackSpace → \x7f) and falls back to key_event_text
for printable characters. Only the control-socket path is touched; interactive
GTK key handling is unchanged.

Test plan

• limux send-key --surface <ref> Return on a bare bash prompt now submits
  the buffered command (verified end-to-end: the command executes and its
  output appears, followed by a fresh prompt).
• Printable keys sent via the socket now reach the shell.
• Interactive typing in a pane is unaffected (helper is only invoked from
  send_key).
• cargo build --release is clean.

Notes

This is the same underlying issue as the send-key Return portion of #108
(which was closed unmerged); this PR is scoped to just the input fix and
extends it to the other common control keys.

[bvolpato]

Blocking: rust/limux-host-linux/src/terminal.rs:183-211 still sends keycode: 0. Ghostty derives physical key only from keycode, so this fixes printable input and four hardcoded controls but leaves arrows, function keys, and physical keybindings unidentified. send-key Up, for example, still has neither text nor physical key and cannot produce its PTY sequence.

Map keyval to display keycode as #114 does, then verify Return plus one non-text key end to end. Socket-only scope and CString lifetime look good.

nonblocking: no regression coverage or CI result currently exercises non-text keys or terminal keyboard modes.

(Review assisted by gpt-5.6-sol)

[bvolpato]

Current quality check is green, but current head still has two functional blockers:

• terminal.rs:183-198 sends keycode: 0. Ghostty resolves physical key only from keycode, so arrows, function keys, and physical bindings remain unidentified even though printable text and four hardcoded controls work.
• main.rs:763-765 uses shell echo for arbitrary --shell-safe payloads. dash and zsh interpret backslash escapes; payload containing \c is truncated and \t is changed. Use quoted printf '%s\n' or equivalent byte-preserving command.

Latest shell-safe tests only assert generated source string, so they miss target-shell interpretation. Please map keyval to display keycode and test shell output with escape-bearing payload.

(assisted by gpt-5.6-sol)