demo: one core for all sessions, lowest priority, 1 GiB; Try it deployed [skip ci]

An idle StarshipOS guest keeps a host core 100% busy (measured 2026-11-08:
QEMU at 100% of a core, 148 MiB, the guest idle at its prompt; #151).
starshipos-demo.service: CPUQuota=100% and Nice=19 for all sessions
together, MemoryMax=1G -- sized for this server, where the old 300% and 4G
let two visitors starve both wikis and Gitea. DEPLOY.md says how to apply
it. FABRIC-3 XLVIII.4: Try it deployed and checked from outside; the ttyd
package's own login service; #151, #152.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2

demo/DEPLOY.md

@@ -89,4 +89,8 @@ goes into the .com's navigation (#117).
 
 - `journalctl -u starshipos-demo -n 50` -- ttyd and the sessions
 - A session that ends at once: the saved machine does not match (re-run step 3)
-- Memory: `free -h` -- each session is ~400 MB of QEMU; two at most (`DEMO_MAX_GUESTS` in the service)
+- Memory: `free -h` -- a session's QEMU holds ~150 MB of its 384 MiB guest; two at most
+  (`DEMO_MAX_GUESTS` in the service)
+- CPU: an idle guest keeps a host core busy (the kernel's idle loop polls -- its own issue), so the
+  service caps all sessions together at one core (`CPUQuota=100%`, `Nice=19`). After changing the
+  service file: `systemctl daemon-reload && systemctl restart starshipos-demo`

demo/starshipos-demo.service

@@ -30,8 +30,14 @@ ProtectHome=yes
 PrivateTmp=yes
 PrivateDevices=yes
 ReadOnlyPaths=/var/lib/starshipos-demo
-MemoryMax=4G
-CPUQuota=300%
+# Sized for this server (3.8 GiB, both wikis, Gitea, Nexus, CI): an idle StarshipOS guest keeps a
+# host core busy -- the kernel's idle loop polls (measured 2026-11-08: 100% of a core at the
+# prompt, 148 MiB resident) -- so all sessions together get one core at the lowest priority, and
+# the wikis and Gitea never starve; with two visitors each runs at half speed. 1 GiB holds two
+# sessions with room. Raise both with the server (8 GB: MemoryMax=2G, CPUQuota=200%).
+MemoryMax=1G
+CPUQuota=100%
+Nice=19
 TasksMax=200
 
 [Install]

docs/fabric/FABRIC-3.md

@@ -6243,3 +6243,20 @@ review list begun meanwhile goes to the milestone v4.0.0-alpha.4.
 - With both wikis up again (Shenandoah, the .com's heap at 512 MiB, the .org's given 256 more): the
   server at 2.6 of 3.8 GiB used, 1.2 GiB available, 2 GiB of swap used; Build 204 (three images, the
   v4 tests) passed alongside them.
+
+### 4. Try it, deployed (2026-11-08)
+
+Captain Bob ran `demo/DEPLOY.md` on the server (#115): try.starshipos-f18.com with its own Let's
+Encrypt certificate, ttyd behind Apache, framing allowed to the .com alone. Checked from outside: a
+session ready 1.5 s after the page opens, `3 4 + .` -> `7  ok`, `: SQUARE DUP * ;  7 SQUARE .` ->
+`49  ok`, a third visitor at once told every machine is busy.
+
+Found on the way:
+- Ubuntu's `ttyd` package starts its own `ttyd.service` -- `login` on port 7681, ours -- and
+  until it was disabled the page served the server's login prompt to anyone. `DEPLOY.md` step 4
+  now disables it first and checks what listens on 7681.
+- **An idle StarshipOS keeps a host core 100% busy** (#151): the demo machine at its prompt, idle
+  20 s, QEMU at 100% of a core, 148 MiB resident -- the kernel's idle loop polls, never halts. Two
+  visitors' sessions with Gitea's diff statistics on a burst of pushes (#152, 1.75 GiB) filled the
+  server's swap and stalled both wikis. The service now caps all sessions together at one core at
+  the lowest priority (`CPUQuota=100%`, `Nice=19`, `MemoryMax=1G`), until #151 is fixed.