Parent: #502 Depends on: #978 Related: #461, #492
Problem
#978 creates one typed boundary for every production OS thread, but the process still cannot answer how many resources are live, how many starts failed, what peak concurrency occurred, or how much configured native-stack reservation each class represents. Admission and pressure decisions would otherwise need a second, drifting accounting path.
Scope
- Add exact per-resource counters at the typed spawn boundary: attempts, successful starts, completions, spawn failures, live/peak threads, and current/peak configured stack bytes.
- Provide a coherent process-wide snapshot under concurrent starts and exits without serializing thread execution.
- Export the snapshot through the public Zig module as the machine-readable base for later coordinator policy and benchmark diagnostics.
- Pin concurrent lifecycle, peak, stack, failure/in-flight invariants, and zero-live teardown behavior.
Acceptance
- Every #978 resource kind is represented in a fixed schema and uses the same accounting path.
- Snapshot invariants are exact under concurrent start/exit: attempts = starts + failures + in-flight attempts; live = starts - completions; current configured stack bytes return to baseline after join.
- Snapshot reads cannot combine fields from different completed mutations.
- Focused normal and TSan concurrency tests, runtime-thread audit, full units, and docs pass.
- No admission or scheduling behavior changes in this slice; counter overhead is paid only at OS-thread creation/exit.