Wait for client inventory readiness before player admission

docs/preparation-status.md

@@ -1,5 +1,57 @@
 # Mission preparation presentation
 
+## Client inventory readiness (0.0.7 candidate)
+
+The user reported arriving before loot was available with 0.0.6. The client's
+16:57 session acknowledged all 41 scene objects in about 203ms, but that check
+only resolved replication entities. It did not verify that items were linked
+into usable inventories. Native resource preload also ran concurrently and
+could finish before the dynamic scene arrived.
+
+Admission now snapshots the current physical contents of nearby scene inventory
+managers and the pending prisoner. The client must resolve the objects and find
+every required item in its corresponding manager's inventory before acknowledging
+readiness. Only then does native asset preload start; assignment still waits for
+its completion and the existing admission checks. A spawn-position replication
+observer is installed before the wait, then restored on cleanup, preserving
+streaming while asset preload is deferred. There is no additional fixed delay.
+
+While admission is pending, the server checks the current contents every 500ms.
+Changed contents create a new token and require another acknowledgement and
+preload pass, so a late joiner does not indefinitely wait for stock another
+player has already taken. The 60-second scene deadline is not extended by these
+refreshes. A timeout rejects and retries the attempt rather than admitting a
+player with missing equipment. The 256-node snapshot cap remains enforced.
+
+`tests/test_spawn_scene_inventory.py` executes the production snapshot, inventory
+containment, refresh and preload-gating methods. It covers delayed inventory
+links after entity arrival, missing items/managers, wrong-owner contents,
+deduplication, snapshot limits and consumed stock. `tests/test_spawn_scene.py`
+also checks that ready objects alone cannot acknowledge missing inventory and
+that native preload starts after acknowledgement. These controlled adapters and
+local Workbench tests cannot establish dedicated-client replication timing.
+
+Repository checks passed. In the final-source native run at 17:24 on September
+20, all 50 scene objects and 28 inventory items were acknowledged at 17:25:13.889,
+asset preload began at 17:25:13.894, and the admission assertion passed at
+17:25:15.320. That run subsequently failed in vanilla
+`SCR_AIGetSuppressionVolumePosition` with `No suppression volume provided!`;
+it is not a successful full-mission verdict. Its original cleanup report also
+retains a transient exiting-process classification error. A separate follow-up
+confirmed the disposable prefix idle and addon sources identical to the launch
+snapshot. Raw results remain under
+`/tmp/erri-spawn-inventory-final-20260920/logs/logs_2026-09-20_17-24-20`.
+
+The unchanged-source repeat at 17:26 completed victory and 105 assertions with
+no script/runtime errors. It again confirmed inventory acknowledgement, subsequent
+asset preload, then admission. The four existing RHS/WCS localization errors
+remain. Its runner also recorded the transient cleanup classification failure;
+the separate follow-up confirmed an idle prefix and unchanged source without
+rewriting that result. Results are under
+`/tmp/erri-spawn-inventory-repeat-20260920/logs/logs_2026-09-20_17-26-51`.
+Publish the candidate and update both RKS #2 and the client before testing a fresh
+join and a late join; the Workshop/server package was not changed by these tests.
+
 ## Dedicated replication barrier (0.0.4)
 
 The user retested 0.0.3 on RKS #2 and reported that the black preparation screen