Settle the MCP in-flight gauge for clients that hung up before serving - #1577

Summary

The mcpRequestsInFlight gauge in the vitals line drifted up by about 540 per container-day on Cloud while open sockets and memory stayed flat. serveStateless adds its res.once('close') listener only after auth, tenant checks and tool planning. When a client hangs up during those steps, close has already fired, the listener never runs, and the decrement (and the mcpAbortedTotal count) is lost. Each jump matched a burst of 70-150 requests that one workspace's node client aborted within 1 s (1,278 such aborts on 7-8 Nov).

Monitoring only: no memory or behaviour impact for customers. Same behaviour on Cloud and self-hosted.

Changes

• trackMcpRequestClose() (exported from mcp-endpoint.controller.ts) holds the close handling that was inline in serveStateless.
• A response that is already closed or destroyed is settled right away (decrement + abort count) instead of waiting for a close that will not come again.

Type

• Bug fix

Testing

• Added/updated unit tests: mcp-request-close.spec.ts (normal close, abort before answer, already closed, already destroyed with no double decrement, mock without once).

In packages/backend (after npm ci and npx prisma generate):

• npx jest --maxWorkers=4 src/mcp-server/mcp-request-close.spec.ts src/mcp-server/mcp-endpoint.controller.spec.ts: 2 suites, 57 tests passed.
• npx tsc --noEmit -p tsconfig.json: clean.
• npx eslint on both files: clean.

Checklist

• My code follows the existing code style
• I have tested my changes locally
• I have updated documentation (if applicable): not applicable
• All existing tests pass: full backend suite runs in CI
• This PR has a descriptive title

Related Issues

Found in the 2026-11-08 daily check (Cloud backend vitals line).