test(web): pin the npm wait floor for update everything

apps/web/src/components/sidebar/updateEverything.logic.test.ts

@@ -88,15 +88,17 @@ describe("collectServerUpdateTargets", () => {
 
   it("waits for npm only for hosts that install from it or when the release may lack archives", () => {
     const hosts = [
-      machine("archive-service", "0.1.4", "boot-service"),
-      machine("npm-service", "0.0.40", "boot-service"),
-      machine("legacy-respawn", "0.1.4", "respawn"),
-      machine("desktop", "0.1.4", "desktop-managed"),
+      machine("archive-service", "0.0.41-nightly.20260914.1700", "boot-service"),
+      machine("npm-service", "0.0.41-nightly.20260914.1699", "boot-service"),
+      machine("legacy-respawn", "0.1.4-nightly.20261027.3796", "respawn"),
+      machine("desktop", "0.1.4-nightly.20261027.3796", "desktop-managed"),
     ];
     const waits = (releaseArchivesPublished: boolean) =>
-      collectServerUpdateTargets(hosts, "0.1.5", releaseArchivesPublished).waitForNpm.map(
-        (target) => target.serverLabel,
-      );
+      collectServerUpdateTargets(
+        hosts,
+        "0.1.5-nightly.20261029.3873",
+        releaseArchivesPublished,
+      ).waitForNpm.map((target) => target.serverLabel);
 
     expect(waits(true)).toEqual(["npm-service", "legacy-respawn"]);
     expect(waits(false)).toEqual(["archive-service", "npm-service", "legacy-respawn"]);

docs/operations/release.md

@@ -432,9 +432,10 @@ release archives, and then its npm launcher, available before users can receive
 The workflow enforces this ordering:
 
 1. `release` publishes the GitHub Release with the CLI archives and `SHA256SUMS`. Every channel
-   uploads to a draft and publishes only after all assets are attached, so a version in the
-   desktop update feed always has its archives. **Update everything** relies on this to update
-   background-service hosts before npm has the version.
+   uploads to a draft and publishes only after all assets are attached, so a new version in the
+   desktop update feed already has its archives. **Update everything** relies on this to update
+   background-service hosts before npm has the version. Rerunning `release` after publication
+   replaces assets in a public release, so service updates can fail until the upload finishes.
 2. `publish_cli` publishes the `t3@<version>` launcher, which downloads from that release, on every
    channel.
 3. `deploy_web` depends on both before moving the hosted channel to the new client.

docs/user/updating.md

@@ -22,11 +22,11 @@ restart from the update button when you are ready. A server still restarting
 finishes on its own, and the button keeps showing it after the desktop app
 restarts.
 
-Remote desktop apps never wait for npm. Background services do not wait either
-when the version comes from the desktop app's update. Other server updates
-appear only after that version is published to npm. The confirmation lists each machine it skips
-and why, such as a machine that is offline or needs a manual update. Use
-**Settings → Environments** for those.
+Remote desktop apps never wait for npm. When the desktop app offers the update,
+background services update right away too. Other servers, including older
+background services, update only after that version is published to npm. The
+confirmation lists each machine it skips and why, such as a machine that is
+offline or needs a manual update. Use **Settings → Environments** for those.
 
 If a desktop app restarts on its old version, T3 Code tells you the update did
 not apply. It does not install that version again on its own, even when another