Simplify game files to automatic T5 and T6 uploads

docs/native-hosts.md

@@ -18,17 +18,19 @@ the agent owns local execution and its durable operation journal.
    installation, verifies the downloaded agent and updater SHA-256 over HTTPS,
    enrolls it and enables `electric-cherry-agent.service` and its automatic update
    timer. It needs no Git, Node.js or local build.
-4. In **Game Files**, select T5 or T6 and upload your local game folder. Name the
-   library and version and publish
-   it after the upload finishes. Include the DLC files in that folder; there is
-   no separate DLC declaration. Uploading also works before enrolling any host.
+4. In **Game Files**, upload your complete local folder under T5 or T6. Include
+   the DLC files in that folder; there is no separate DLC declaration, library
+   name or version label. The upload becomes the latest files for that game after
+   verification. Uploading also works before enrolling any host.
 5. Hosts automatically prepare the configured Plutainer runtime and the latest
-   published version of every game library. **Automatic host setup** reports
+   verified T5 and T6 files whenever available. **Automatic host setup** reports
    progress and errors. Wait for verification before launching. Hosts report
    connection and readiness separately; deployment also checks the particular
-   library, image, capacity and ports you selected.
-6. Launch a server or collection. Select the host, immutable game-file version(s)
-   and use the automatically selected default runtime, or an advanced override.
+   game files, image, capacity and ports required for the launch.
+6. Launch a server or collection. Select the host; 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.
    Saved Plutonium server keys remain associated with their exact server names.
 
@@ -37,19 +39,25 @@ copying or per-container setup. EC does not supply the game content itself.
 
 The controller reconciles automatic setup on agent heartbeats and operation
 polls. It first pulls `PLUTAINER_IMAGE` (default
-`ghcr.io/ayymoss/plutainer:latest`), then prepares the newest published version of
-each library, one setup operation at a time. Publishing more files or enrolling
-another host needs no manual propagation. Setup waits for an active, connected,
+`ghcr.io/ayymoss/plutainer:latest`), then prepares the latest verified upload for
+T5 and for T6 when available, one setup operation at a time. Uploading new files
+or enrolling another host needs no manual propagation. Setup waits for an active, connected,
 healthy host with sufficient storage. Failed operations retry automatically with
 backoff from one minute to fifteen minutes; their errors remain visible in the
 host's setup panel and operation history. Disconnected hosts resume when they
 reconnect. Draining and disabled hosts do not receive new automatic setup work.
 
-Verified older versions remain cached and running servers keep their selected
-files and runtime. Automatic setup ensures that the configured image is present;
-it does not refresh an already cached mutable image tag. Advanced controls on the
+An automatic download that has not been delivered to the agent can be replaced
+when a newer upload becomes available. A delivered operation finishes safely
+before the host prepares the latest files. Failed or incomplete uploads never
+replace the latest verified files.
+
+Verified previous uploads remain cached and running servers keep their existing
+files and runtime; uploading new files does not restart servers. Automatic setup
+ensures that the configured image is present; it does not refresh an already
+cached mutable image tag. Advanced controls on the
 host and game-file pages can explicitly pull a custom runtime, prepare an older
-library version or retry preparation immediately.
+upload or retry preparation immediately.
 
 The default host root is `/var/lib/electric-cherry`; installer `--data-dir` changes
 it. Use a dedicated, root-owned directory. For a separate disk, use a child of its
@@ -160,8 +168,13 @@ API outline:
 - `POST /api/agent/operations/:id`: authenticated acceptance, progress or result.
 - `POST /api/agent/decommission/:id`: cleanup worker reports file removal and
   agent uninstall using its own operation-scoped receipt credential.
-- `POST /api/game-files`: administrator creates a folder upload with game, name,
-  version, optional description and `files: [{path, size, lastModified}]`.
+- `GET /api/game-files`: returns `{libraries, hosts}`. `libraries` always contains
+  two game slots, T5 and T6, including empty slots. Each slot has a nullable
+  `latestVersionId` identifying its latest verified upload, plus upload history.
+- `POST /api/game-files`: administrator creates a folder upload with
+  `{game: "t5" | "t6", files: [{path, size, lastModified}]}`. Upload IDs and
+  internal revision metadata are generated automatically; no library name,
+  version label or description is required.
 - `GET /api/game-files/:id/upload`: durable per-file offsets and publication status.
 - `PUT /api/game-files/:id/upload/files/:path`: administrator uploads a raw chunk
   with `X-Upload-Offset`, `X-Upload-Length` and `X-Content-SHA256` headers.
@@ -243,7 +256,13 @@ retries the completion receipt from memory. A power loss in that final window
 can leave the controller awaiting confirmation even though removal succeeded;
 inspect the machine if that status persists. The controller does not guess.
 
-## Libraries and ports
+## Game files and ports
+
+Game Files always shows T5 and T6, each with its own upload button and latest
+verified files. Successful uploads become latest in publication completion
+order, not by their start date or an entered label. A newer upload still being
+transferred or verified leaves the current files available. Previous uploads
+appear in history, and interrupted uploads can be resumed separately.
 
 Choose the actual game folder, not its parent, a ZIP archive or the Plutonium
 launcher data folder. The selected folder's name is removed once; nested paths
@@ -262,23 +281,26 @@ unchanged folder; relative paths, sizes and modification times must match. Keep
 the page open while transferring. Once publication starts, the controller hashes
 every complete file and publishes the directory atomically; closing the browser
 does not stop that verification. An interrupted controller can retry publication.
-Published versions cannot be updated;
-changing files requires a new version. Hosts download up to four files
-concurrently with HTTP Range resumption, report progress, verify all checksums
+Verified uploads are immutable; changing files means uploading another folder
+for the same game. Hosts download up to four files concurrently with HTTP Range
+resumption, report progress, verify all checksums
 and atomically promote the complete cache. Checksums are calculated while bytes
 arrive, avoiding another complete read of newly downloaded files. Resumed files
 include their saved prefix in verification. Progress reports are rate-limited so
 controller round trips do not stall every transferred chunk.
 Corrupt or incomplete content never becomes Ready. Cache inventory is reconciled
-on heartbeats, including vanished caches. Older immutable versions remain usable
+on heartbeats, including vanished caches. Previous immutable uploads remain usable
 when their exact manifest is verified.
 
 The controller and reverse proxy must accept 8 MiB upload requests and folder
 manifests up to 32 MiB. Compose sets `BODY_SIZE_LIMIT=Infinity`; application routes
 still enforce these limits, declared file sizes and checksums. Set a proxy body
 limit of at least 32 MiB (for example `client_max_body_size 32m` in nginx).
-Existing published versions and cached host libraries remain usable after the
-upload workflow replaces source-host imports.
+Existing uploads, host caches and server references remain usable. Previously
+named libraries are grouped under T5 or T6, and the most recently published
+upload for each game becomes its latest files. Their immutable IDs and stored
+content are preserved; no reupload is needed. Legacy source-host imports retain
+their existing IDs and can complete through their original workflow.
 
 Reservations include host ID, local bind address, protocol and port. Wildcard
 binds conflict with concrete addresses on the same host. UDP and TCP reservations