fix(mcp): stop the remote command and close its channel when run_command times out

[doublewhy]

Summary

run_command runs through SSHConnectionManager.executeCommand with the fixed 30 s default timeout. When the timer fired, executeCommand rejected but kept no reference to the exec channel: the channel stayed open, the remote command kept running, and every chunk it wrote was still appended to the result buffers inside the MCP server (evidence and a hermetic reproduction in #1290). This PR stops the command and closes its channel when the timer fires.

Changes

mcp/aptl-mcp-common/src/ssh-manager.ts:

• executeCommand keeps the channel. On timeout the new stopTimedOutCommand sends TERM with ssh2's ClientChannel.signal(), then close(), before the promise rejects. A channel the server opens only after the timer fired is stopped the same way as soon as it opens.
• Late output still reaches the capture tee (ptyTee) but is no longer buffered; one collect helper holds that guard for both data handlers.
• ssh2 throws from signal()/close() once its connection is torn down (Instance unusable after …); stopTimedOutCommand catches and logs it, so it cannot crash the server from the timer.
• The rejection message, the 30 s default and the success path are unchanged.

tests/ssh.test.ts adds a #1290 block that drives the real executeCommand through a stub connection and an EventEmitter channel with stderr, signal() and close(). No file is added or removed and no lockfile changes, so the inventory and MCP lockfile digests are unchanged.

Done-when matrix

Tests are in the #1290 block, run by CI's MCP TypeScript tests + coverage job (npx vitest run --coverage in mcp/aptl-mcp-common; passed in Checks run 38226224239). "Stash" = dev's ssh-manager.ts restored with git stash push.

Done-when (verbatim)	Change	Test	Without the fix
A test with a mocked channel shows that the timeout signals the command, closes the channel once, and rejects with the unchanged timeout error.	ssh-manager.ts:stopTimedOutCommand, executeCommand	signals the command, closes the channel and stops buffering when the timer fires	stash: fails, signal never called with TERM
Output that arrives after the timeout is not buffered, and the capture tee still records it.	ssh-manager.ts:executeCommand (collect)	same test (tee records out, out, err)	stash: fails; collect guard alone removed: fails (late chunk's toString called 2 times)
A channel that opens after the timer fired is signalled and closed.	ssh-manager.ts:executeCommand (exec callback)	stops a channel the server opens only after the timer fired	stash: fails, signal never called with TERM
A command that finishes in time resolves as before and is neither signalled nor closed.	success path, unchanged	leaves a command that finishes in time alone	passes on both; guards the success path

still rejects when ssh2 throws because the connection is already gone fails under stash (nothing logged) and with the try/catch removed (Instance unusable after fatal error escapes the timer).

Scope

• TERM is coreutils timeout(1)'s default and lets a wrapper finish its records (the capture broker does: containers/kali-capture/broker.py:466-470); the close follows, so there is no second signal.
• OpenSSH accepts signals only for sessions without a forced command (OpenSSH 7.9 release notes, bz#1424; session_signal_req in session.c). The Kali path runs ForceCommand /usr/local/bin/broker.py (sshd_config:19), so there the close ends the session: the broker's next write fails and its cleanup terminates the inner ssh process group (broker.py:507-516). This path is established by reading the code; the real-server verification is tracked in Verify the run_command timeout against a real sshd running the capture broker #1384.
• Out of scope, as run_command leaves the remote command running and buffering after its timeout #1290 lists: harvesting after a timeout (Harvest Kali captures for a run_command that timed out #1319), a per-call run_command timeout (The run_command tool has no per-call timeout #1320), and the persistent-session command timeout in ssh-session.ts:343-352 (A persistent-session command timeout leaves the command running #1318).

Overlap with #1279

#1279 (#967) edits other functions in the same two files. On dev 1abe440, git merge-tree --write-tree --name-only HEAD 22afced2 for this head and #1279's head 22afced is clean (exit 0, tree 76eb78b6) and keeps both PRs' changes.

Verification

Head 083df5a, based on dev 1abe440, Node 22.23.3, npm 10.9.9.

• Before the fix, a probe drove dev's built executeCommand with a 200 ms timeout: it rejected with Command timeout after 200ms: nmap -sV 10.0.0.5, then took 1,000 late 1 KiB chunks with 0 signal() and 0 close() calls and buffered all 1,000.
• mcp/aptl-mcp-common: npm ci, npm run build, npx tsc --noEmit passed; npx vitest run on the 9 test files touching executeCommand, run_command, ssh-manager and the areas fix: repair Wazuh rule authoring through MCP #1251/fix(mcp): harvest Kali captures from the workspace-scoped capture container #1257 changed: 201 passed.
• mcp/mcp-red rebuilt against this common build: npx vitest run tests/capture.test.ts tests/logger.test.ts 67 passed. The eight dependent MCPs built with npx tsc -p tsconfig.build.json on the previous rebase.
• pre-commit run --files on both files and the ESLint complexity gate from .pre-commit-ci.yaml passed.
• Local runs used no Docker, lab or real SSH server; CI runs the full MCP and Python suites and the restricted-SSH transport tests. A run against a real sshd with the ForceCommand capture broker is not in run_command leaves the remote command running and buffering after its timeout #1290's done-when and is tracked in Verify the run_command timeout against a real sshd running the capture broker #1384.
• CI on 083df5a: Checks 38226224239, PR 38226220117 and PR Title Lint 38226236181 succeeded; 44 checks pass, the Trivy summary is neutral (checked 2026-10-13).

Requirement UIDs: none (bug/maintenance).

Closes #1290