fix(mcp): isolate concurrent stdio PID attribution

[silverstein]

Summary

• serialize only stdio MCP process creation and PID snapshot attribution
• keep MCP sessions concurrent after each child has been assigned to its owning server
• use a loop-neutral threading.Lock so attribution still works after Hermes recreates its MCP asyncio loop
• add a behavioral regression that starts two servers concurrently across two separate event loops and verifies exact PID ownership

Problem

The existing snapshot after - snapshot before attribution can run concurrently for multiple stdio MCP startups. Each startup can therefore observe the other server's child and record the wrong PID/PGID. That can contaminate liveness and cleanup ownership, including targeting the wrong process group during teardown.

Scope

This is the focused PID-attribution/spawn-lock portion split from #95290 at the maintainer's request. It does not include the already-landed child-liveness polarity fix, reconnect-on-fast-fail work being salvaged in #96452, or the separate stdio idle-probe redesign.

Verification

• all MCP tests: 593 passed, 0 failed, 1 skipped
• focused stdio attribution/liveness tests: 11 passed
• Ruff passed
• git diff --check passed

[silverstein]

Independent exact-SHA review completed: PASS, no findings.

• Base: 42ac29eacc4d743ed2df7db0f886b99111d9e68b
• Head: 9340648f7c4812d2a2fa3e73d132b0b80b9d8bcf
• Reviewer checked lock acquisition/release, cancellation and exception paths, cross-loop reuse, PID ownership isolation, session concurrency, and behavioral-test coverage.

[alt-glitch]

This was generated by AI during triage.

Duplicate of #67736: both patches serialize the same stdio PID-attribution window. #67736 is earlier and has broader concurrency coverage.