fix(wrapper): add timeouts to tmux send-keys and stop ignoring its exit status

[Lafnaps]

inject() in wrapper_unix.py runs tmux send-keys twice (the text, then Enter) with capture_output=True and no timeout=. If the tmux server wedges, the call blocks forever — and it blocks the queue-watcher thread with it, so delivery stops permanently: the watcher monitor only replaces dead threads, and this one is still alive. The wrapper looks healthy while the agent never receives another mention until a manual restart. (capture-pane in get_activity_checker already runs with timeout=2; send-keys was left unbounded.)

The exit status is ignored on both calls, too. When the target session has died, send-keys fails with rc=1, nothing reaches the composer, and the mention is gone — the watcher had already consumed the queue — with zero diagnostics.

This bounds both calls with a 5s timeout and makes the outcome explicit: "deferred" when tmux positively rejected the text command (nothing reached the composer, a retry is safe), "injected-uncertain" on a timeout or a failed Enter after the text already went in (retyping at that point could duplicate or even submit a half-typed prompt), "injected" when both succeeded. The watcher doesn't act on the result yet — the immediate fix is that a wedged tmux can no longer hang delivery — but the contract is there for a caller that wants to retry the safe case.

Test plan: new tests/test_wrapper_unix_inject.py with a mocked subprocess.run — success is reported only when both sends succeed; rc!=0 on the text send is deferred/retryable; a timeout is uncertain. No tmux needed to run them → 2 passed. Full suite: 83 passed (81 on current main).