fix: spawn supervisor child to avoid OpenSSL fork deadlock

[kaiitunnz]

Purpose

Fixes an intermittent server-startup hang where the FastAPI lifespan times out with Supervisor child did not register a node within 30s (child still alive). The hang reproduces roughly 1-in-5 to 1-in-10 stack boots and is more likely after a stack restart that overlaps with other docker activity.

Also addresses two newly disclosed CVEs that started failing pip-audit on this PR — starlette PYSEC-2026-161 is resolved on the server by bumping fastapi; diffusers GHSA-7wx4-6vff-v64p and the worker-GPU starlette exposure are silenced because both upgrades are blocked by existing pins.

Changes

• src/server/supervisor/supervisor.py — spawn the supervisor child via mp.get_context("spawn") instead of the default fork. Widen the process annotation to BaseProcess | None so spawn's SpawnProcess type-checks.
• src/server/utils/concurrent.py — create_task_channel now creates its IPC queues from the same spawn context, so the SemLocks inside are spawn-compatible (mixing fork and spawn primitives raises RuntimeError at spawn time).
• pyproject.toml / uv.lock / src/server/requirements.txt — bump fastapi>=0.135.0 so the server pip-audit picks up a starlette past the PYSEC-2026-161 fix.
• .github/workflows/security.yml + docs/CODE_STYLE.md — add --ignore-vuln entries for GHSA-7wx4-6vff-v64p (diffusers, all worker steps) and PYSEC-2026-161 (starlette, worker-GPU only), with matching rows in the advisory table. Both upgrades are blocked there by existing transitive pins.

Design

The parent server opens Redis-over-TLS connections during lifespan startup, which initialises OpenSSL state in the parent process. OpenSSL is not fork-safe — random-pool state and internal locks inherited via fork() can deadlock the child the first time it calls ssl.SSLContext.__new__. We caught the child stuck there with a faulthandler thread dump, inside redis-py's SSL connect path on SyncRedisClient.ping().

Switching to spawn execs a fresh Python interpreter for the child, so OpenSSL initialises cleanly. The spawn overhead is ~0.5–1 s and pays only once per stack boot.

Test Plan

uv run pre-commit run --all-files
uv run pytest tests/ --ignore=tests/worker/test_mp_executor_cleanup_gpu.py
uvx pip-audit==2.9.0 --strict $(<ignore-list>) -r src/server/requirements.txt
uvx pip-audit==2.9.0 --strict $(<ignore-list>) -r src/worker/requirements/requirements.txt
uvx pip-audit==2.9.0 $(<ignore-list>) -r src/worker/requirements/requirements.gpu.txt

E2E (local stack, no plugin scenarios):

• flowmesh stack up × 25 consecutive cycles with worker up cpu 1 mixed in — 25/25 healthy, zero handshake timeouts. Pre-fix, the same loop reproduced the timeout at ~1 in 5–10 cycles.

Test Result

$ uv run pre-commit run --all-files
# all hooks pass on the touched files; pre-existing mypy errors elsewhere unchanged

$ uv run pytest tests/ --ignore=tests/worker/test_mp_executor_cleanup_gpu.py
977 passed in 44.18s

$ uvx pip-audit==2.9.0 --strict ... -r src/server/requirements.txt
$ uvx pip-audit==2.9.0 --strict ... -r src/worker/requirements/requirements.txt
$ uvx pip-audit==2.9.0          ... -r src/worker/requirements/requirements.gpu.txt
No known vulnerabilities found (0 ignored server, 13 ignored CPU, 21 ignored GPU)

25-cycle stress loop: PASS=25 FAIL=0.

---

Pre-submission Checklist

• I have read the contribution guidelines.
• I have run pre-commit run --all-files and fixed any issues.
• I have added or updated tests covering my changes (if applicable).
• I have verified that uv run pytest tests/ passes locally.
• If I changed shared schemas or proto definitions, I have checked downstream compatibility across Server and Worker.
• If I changed the SDK or CLI, I have verified the affected packages work (uv sync --all-packages --group ci --frozen).
• If this is a breaking change, I have prefixed the PR title with [BREAKING] and described migration steps above.
• I have updated documentation or config examples if user-facing behavior changed.

[timzsu]

One minor comment. PTAL.

[timzsu]

Do we need this line? I have locally experimented and found that bumping fastapi to >=0.135.0 can solve this ignore cleanly. (The doc addition mentions that the ignore is due to vllm-omni, which is not installed in the server environment).

[kaiitunnz]

Fixed by removing the line and bumping FastAPI bound.

[timzsu]

LGTM.