fix(tui-rpc): register the missing shell.exec handler

[AmirF194]

Summary

!-prefixed bang commands in the TUI always fail with [rpc -32601] method_not_found. useSubmission.ts's shellExec and interpolate call gw.request('shell.exec', {command}), but the backend never registers a shell.exec handler; it is absent from every dispatcher.register(...) call in raven/**/*.py.

#171's root-cause section points at a different method, command.dispatch, based on evidence gathered against the released v0.1.6 bundle (ui-tui/dist/entry.js, a gitignored build artifact). That name is gone from the current frontend source: command.dispatch only survives as dead code in createSlashHandler.ts's .catch() fallback, which is unreachable because slash.exec never rejects (see its own docstring). On current main, useSubmission.ts:180 and :212 call shell.exec directly for every bang command, and that is the method that is actually unregistered. Registering command.dispatch per the issue's suggested fix would not have fixed the bug on current main.

shell.exec carries no session_id (both call sites pass only {command}), so there is no session-scoped sandbox executor to route the command through. The fix runs it via DirectExecutor, the same host-execution path ExecTool falls back to when no sandbox is configured, matching a plain shell escape.

Type

• Fix
• Feature
• Docs
• CI / tooling
• Refactor
• Other

Verification

Reproduced end to end in a clean python:3.12-slim container (uv sync --frozen --extra dev --dev):

$ python3 -c "
import asyncio
from raven.tui_rpc.dispatcher import Dispatcher
from raven.tui_rpc.methods import register_aligned_methods_except_system
d = Dispatcher()
register_aligned_methods_except_system(d)
print('shell.exec' in d.methods())
frame = {'jsonrpc':'2.0','id':1,'method':'shell.exec','params':{'command':'echo hi'}}
print(asyncio.run(d.dispatch(frame)))
"
# main:   False, {'error': {'code': -32601, 'message': 'method_not_found', 'data': {'method': 'shell.exec'}}}
# branch: True,  {'result': {'code': 0, 'stdout': 'hi\n', 'stderr': ''}}

• Relevant tests pass locally: new tests/test_tui_rpc_shell_exec.py (registration, stdout capture, non-zero exit code, empty-command guard) fails to import on main (module does not exist yet) and passes on this branch (4 passed), in the same container. Also ran the full tests/test_tui_rpc_*.py suite (380 tests) to check for regressions: all pass.
• Relevant lint / type checks pass locally: ruff check / ruff format --check on the changed files, and pre-commit run --files <changed> (ruff, trailing-whitespace, end-of-file-fixer, large-files, merge-conflict, private-key), all clean.
• User-facing docs or screenshots are updated when needed: no user-facing docs describe shell.exec, none needed.

Not verified: make test-python only runs a fixed list of four test files (test_commit_lint.py, test_large_file_check.py, test_cli_smoke.py, test_litellm_setup.py), which does not include this or any other test_tui_rpc_*.py file, so CI's python checks job will not execute the new test. I ran it manually in the container described above; ran the fixed CI list too (58 passed) with no regressions.

Risk

• Security impact considered: shell.exec runs on the host with no sandbox, same as the existing cli.dispatch path for non-sandboxed setups; it is reachable only from the local TUI subprocess bridge, not the network.
• Backward compatibility considered: purely additive, registers a previously-missing method; no existing handler or contract changes.
• Rollback path is clear for risky changes: n/a, low risk.

Related Issues

Fixes #171