test-stability: isolate flaky remote-auth-branches integration test from parallel load (or root-cause the teardown hang)

[cliffhall]

Problem

The integration test clients/web/src/test/integration/mcp/remote/remote-auth-branches.test.ts → "short-circuits with a transport_error when the session's transport is already dead" intermittently fails with a 30s test / afterEach hook timeout when run under the full npm run coverage / npm run ci gate (v8 instrumentation + all unit & integration projects under parallel load). It passes reliably (10/10) when run in isolation.

Most recently observed during the Wave 2 / Wave 3 rollup ci runs (#1660 / #1655) and earlier across the #1579 Wave-1 smoke audit. Related: #1596 (test-stability).

Proposed fix

1. Move this test (and any sibling that contends on the shared HTTP server start/stop lifecycle) into its own file / vitest project configured to run serially (e.g. fileParallelism: false or a dedicated no-concurrency project), so the transport start/stop teardown isn't racing other integration suites for resources.
2. If isolation does not fix it, root-cause the actual hang. The timeout is in the afterEach stop(h) teardown, which points at the remote HTTP transport / server not closing cleanly when a prior session's transport was already forced dead. Instrument the teardown, determine whether a socket / keep-alive handle leaks under load, and make the teardown deterministic.

Acceptance

• The zero-flake requirement holds: npm run ci passes this test across repeated runs under full parallel / instrumented load.