Queue native collection launches before async placement

docs/native-hosts.md

@@ -34,11 +34,12 @@ Status replies still expire normally, and native timeout diagnostics are retaine
    progress and errors. Wait for verification before launching. Hosts report
    connection and readiness separately; deployment also checks the particular
    game files, image, capacity and ports required for the launch.
-6. Launch a server or collection. The host, latest game files and default
-   runtime are selected automatically after checking capacity. An advanced runtime override is
+6. Launch a server or collection. The latest game files and default runtime
+   are selected automatically. An advanced runtime override is
    available. If the latest files change after previewing, refresh the preview
    before launching.
-   EC selects lobby IDs and reserves UDP/TCP ports atomically.
+   Apply saves the requested lobby IDs. Provisioning selects a host and atomically
+   reserves UDP/TCP ports when capacity is available.
    Saved Plutonium server keys remain associated with their exact server names.
 
 A fresh destination host downloads centrally stored game files without manual
@@ -133,14 +134,19 @@ remain unknown). Scheduling checks capacity against the latest heartbeat and use
 the last five minutes to rank eligible hosts; the Inventory panel shows the latest
 reading.
 
-New servers are placed automatically. Preview and submission perform local
-capacity checks without contacting agents: a connected, active host must have
+New servers are placed automatically. Collection previews use cached availability
+estimates and submission saves unplaced jobs without running capacity checks.
+Provisioning checks each job asynchronously: a connected, active host must have
 verified game files, its runtime, storage, a free UDP/TCP port, and valid CPU and
 memory measurements. Hosts with stale or missing measurements cannot accept new
 servers. Existing API clients may still explicitly constrain a launch to a host.
 
-Admission reserves a provisional host and port atomically, including collection
-launches. Agent **1.4.6** fixes container discovery for resource sampling (the
+Queued jobs retain their accepted game-file version. Automatic host preparation
+also downloads the files and runtime images needed by unplaced jobs; a newer
+upload does not remove files still needed by the queue.
+
+Only provisioning reserves a host and port. Agent **1.4.6** fixes container
+discovery for resource sampling (the
 earlier collector omitted `label=` from its Docker filter). It samples each
 managed running container with a bounded
 [`docker stats`](https://docs.docker.com/reference/cli/docker/container/stats/)
@@ -180,19 +186,19 @@ heartbeat ingestion, at most once per minute per host/fleet phase; new peaks
 raise the cache immediately. Launch admission reads only the cached model.
 
 Scheduling still leaves **5% host CPU and 500 MB RAM (500,000,000 bytes)** for the OS and bursts.
-These allowances are scheduling estimates, not Docker limits. Collection admission
-budgets new and never-submitted queued servers at their running allowance, rather
-than assuming the entire collection starts simultaneously. Current host CPU and
+These allowances are scheduling estimates, not Docker limits. Collection previews
+estimate how many new servers fit at their running allowance. Jobs may still be
+queued when that estimate is insufficient. Current host CPU and
 available memory account for existing containers and other processes. Observed
 containers are not topped up to historical startup or running peaks, even while
 awaiting health verification. Established instances are covered by host usage
 when individual container measurements are unavailable.
 
 Dispatch checks the next launch's startup allowance against live host usage.
-Other never-submitted queued launches wait their turn and retain their port
-reservations. Submitted or uncertain launches missing a matching-generation
+Unplaced queued launches wait their turn without holding physical resources.
+Any previously assigned reservations remain protected. Submitted or uncertain launches missing a matching-generation
 measurement still consume a full startup allowance until telemetry accounts for
-them. This lets collections queue based on running demand and start as capacity
+them. This lets collections start as capacity
 becomes available, without stacking every queued server's startup peak.
 Capacity errors report projected usage, usable capacity and reservations.
 
@@ -201,7 +207,9 @@ current CPU and available memory against reservations and headroom.
 Among hosts that fit, it chooses the lowest projected CPU/memory utilization,
 using the busier of the latest reading and the five-minute average for ranking.
 A historical resource dip cannot block a host whose current capacity has recovered.
-Provisioning moves the provisional reservation atomically and records the final host in the launch recipe. Host network defaults
+Historical ranking runs in a worker thread. The controller rechecks current
+capacity and reserves the selected host and port atomically, then records them
+in the launch recipe. Host network defaults
 are resolved again for the final host; explicit overrides are preserved. If no
 host qualifies, the request waits and is checked again. Once remote staging or
 creation has been submitted, placement stays fixed to prevent duplicate instances.