feat(capture): graph-safe global capture for the filesystem consumer

[RhizoNymph]

What

Gives FilesystemConsumer a working global_capture_spec(). When capture hooks/positions are configured at the consumer level (global_hooks, global_positions, default_tag params), every request is captured uniformly via the CUDA-graph-safe persistent-buffer path, and per-request output files are still written (keyed by the engine request id + the configured tag).

The engine request id was already threaded through the global dispatch path, so no manager plumbing was needed — only the consumer-side spec + naming fallback.

Why

Global capture specs ride a graph-baked persistent-buffer copy and never force eager. The filesystem consumer, being per-request-only, always took the dynamic-gather path that forces a captured decode step out of the CUDA graph (~4x/step; ~+285% at all_generated). For workloads that capture the same layers for all traffic (dataset/reward collection), routing the filesystem consumer through the global path removes that penalty.

Result (Qwen3-0.6B, bs16, cudagraph): all_generated capture overhead +287% → +11%.

Limitations

• Global mode is uniform across requests (one hooks/positions/tag); per-request SamplingParams.capture still overrides per request.
• Packed/sharded layouts are not wired for the global path (they need a per-request admission record); per_file (default) is the intended layout for global capture.

Sibling PRs

Part of a set addressing capture's force-eager-under-cudagraph cost from different angles (graph-safe per-request allowlist; piecewise-eager fallback). These touch overlapping capture files (manager/step_gate/runner/config) and will conflict if merged together — resolve at merge.