[shipiyouniao]

The first DSV4 SWA allocation can block startup when it applies a resize before asynchronous null-block initialization finishes: resize holds the manager lock while the initializer needs that lock to finish. The new exact-ID API has the same ordering problem when called directly.

This moves both readiness waits before synchronized allocation/resize work and preserves initialization errors. It also finds SWA backing through the native HiSparse logical-allocator wrapper so scheduler shrink reclamation reaches the managed pool; HiSparse device-cache allocation remains native. See the backing boundary and exact-ID entry point.

One lifecycle-fix commit above #400 and its #565/#376/#539 dependencies. The four SWA entry-point regression cases fail on the prior code and pass with the wait moved; exact-ID tests exercise the production lock decorator, including empty claims and initialization failure. The equivalent all-manager readiness ordering is included in #566-#569.

Validation at 8d1fb76: 398 targeted CPU tests, the complete CPU manifest (1510 passed; 2 native-tracker and 12 installed-SGLang cases skipped), GPU-free C++, all-file pre-commit, MyPy 3.10–3.13 and private Codex review passed. A single T4 passed 7 native SGLang 0.5.20 storage/runner cases and 2 exact-placement cases, with no skips, using a source-matched extension.

Draft; no full DSV4/MTP serving, graph capture or attention/compressor execution is claimed. Managed backing retains the TP=1 and PP=1 boundary; distributed/unknown topology stays native. Performance remains unmeasured: same-hardware/model/workload comparisons still need throughput, TTFT, TPOT, tail latency, memory and allocation/reclamation overhead, alongside asymmetric multi-rank failure/recovery qualification.