ci: manage.py check spawns MCP stdio children that traceback on teardown

[FlyM1ss]

The Run Django system checks step logs an ExceptionGroup: unhandled errors in a TaskGroup wrapping BrokenPipeError, thrown from mcp/server/stdio.py stdout_writer via mcp/server/fastmcp/server.py run_stdio_async.

Observed in run 30559249310 (PR #364). The step still exits 0, so this is log noise today, not a failure.

Source is app code, not CI: mcp_client/mcp_manager.py spawns stdio MCP servers (StdioServerParameters / stdio_client, L180–186) — sec-edgar-mcp and friends. Django app-loading appears to initialize the manager, so manage.py check boots real MCP subprocesses; when the parent exits, the child's stdout pipe is already closed.

Two things worth deciding:

1. Should a system check start MCP subprocesses at all? If app-load has that side effect, anything importing the Django app tree pays it.
2. If it is intended, the teardown should close the transport cleanly so CI logs do not carry a traceback that reads like a failure.

Not claiming this is new — I could not compare against an older run, as logs before the PR window have been purged. It is definitely unrelated to #364, which only changed --frozen→--locked (identical install set) and PR-event gating.