fix(terminal): name shell-level exit codes 126/127 (Closes #1452)

[Lexus2016]

Child 1 of #1371 (terminal 27.4% failure rate across 673 sessions — the dominant failure signal).

The gap

_interpret_exit_code already explains per-command exit codes (grep 1 = no matches, curl 7 = connection failed) and signal codes (137 = SIGKILL). It said nothing about 126 and 127, because those are not per-command — they are about the invocation. 127 means the shell never found anything to run, whatever the command was, so it falls straight through the per-command table and produced no note at all.

Why these two specifically

The failure is not in the command's logic. Re-running the same string cannot succeed — which is exactly the retry-spiral shape behind the parent issue's numbers. So each note states the cause and what to change:

Code	Note
126	found but not executable; check permissions (chmod +x) or whether it is a directory. Re-running unchanged will fail identically.
127	not found; check spelling, or whether the tool is installed and on PATH. Re-running unchanged will fail identically; try which or an absolute path.

Ordering is the risk, and it is tested

The new lookup is a fallback, matched after the per-command table and the signal codes. Tests pin this:

• grep x f exit 1 still reads "No matches found (not an error)", not a generic shell hint
• curl exit 7 still reads "Failed to connect to host"
• sleep exit 137 still reads "SIGKILL"
• an unknown code still returns None rather than a fabricated explanation

8 new tests, 39 passing in test_terminal_exit_semantics.py, 345 across the terminal suites; ruff clean.

Scope

Deliberately just this. Children 2 (#1453, strategy-switch after 3 consecutive failures) and 3 (#1454, security-scan block directive) are separate — and #1453 in particular needs checking against loop_guard, which already fires on the third consecutive terminal failure today.