games: move tree/worm/sprouty off colliding IPC endpoints

What:
  - tree    31 -> 61
  - worm    29 -> 62
  - sprouty 15 -> 63
Each game's window-input endpoint is reassigned to the top of the
64-wide endpoint space, above the dense boot-service band (14..=33).
Stale "Revisit when: MAX_ENDPOINTS > 32" comments are rewritten and
re-pointed at ADR-018 (the trigger already fired — the bound is 64).

Why:
  Endpoint IDs are ad-hoc `const u32`s with no kernel-enforced
  one-owner-per-endpoint check, and IPC queues are per-endpoint global
  (SHARDED_IPC.shards[endpoint]). Games written months ago picked
  numbers that auto-started boot services later claimed:
    - tree=31 collided with usb-host (live): usb-host blocks on
      recv_verified(31) and drained the compositor's routed input,
      so `play tree` opened a window that ignored all input.
    - sprouty=15 collided with terminal-window's front layer (live) —
      same input-theft mechanism.
    - worm=29 aliases hello-window (disabled in limine.conf) — latent.
  Parking games at 61/62/63 clears every auto-started service.

Out of scope:
  - ping (19) is collision-free; left unchanged.
  - The structural fix is ADR-018's endpoint-reservation table (kernel
    rejects RegisterEndpoint(N) from non-owners). This commit is the
    band-aid that unblocks the games now; high-end parking can still
    re-collide if a service grows past ~34.
  - No kernel changes. Each endpoint is referenced only inside its own
    game crate; the compositor learns it via the Client::open handshake.

Verification:
  - make tree worm sprouty — all three build clean (x86_64).
  - make check-deferrals — 0 new (485 baseline).
  - make check-doc-refs — 0 new (46 baseline).
  - Runtime input routing needs an interactive GUI test:
    make run-gui, then `play tree` / `play sprouty` / `play worm`.

Staged files:
  user/sprouty/src/main.rs
  user/tree/src/main.rs
  user/worm/src/main.rs

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: riccajason

user/sprouty/src/main.rs

@@ -37,27 +37,23 @@ use cambios_sprouty::{
     level,
 };
 
-/// IPC endpoint. `MAX_ENDPOINTS` is a SCAFFOLDING bound of 32 in
-/// [src/ipc/mod.rs], so valid IDs are 0..=31. 22 is free under the
-/// current allocation (16=FS, 17=KS, 18=shell, 19=ping, 20=virtio-net,
-/// 21=udp-stack, 24/25/26=virtio-blk, 27=scanout-driver, 28=compositor,
-/// 29=worm/hello-window, 30=input, 31=tree).
-///
-/// Revisit when: MAX_ENDPOINTS is raised — sprouty moves to
-/// its class-grouped slot (34) alongside Tree=31 / Worm=32 / Ping=33.
-// Was 22 (POLICY_QUERY_ENDPOINT collision). Then 23, which silently
-// collides with `POLICY_RESP_ENDPOINT` -- the kernel hardcodes a
-// "only the policy service may write to ep 23" check in
-// handle_write (src/syscalls/dispatcher.rs:417), so the compositor's
-// Welcome reply to sprouty got -EPERM at the kernel level and
-// sprouty blocked forever on recv_verified.
-// 15 is in the kernel-task grant range (0..16 per
-// capability_manager_init) but no service registers there, and
-// the kernel has no hardcoded intercept on it. After Phase 3.4
-// MAX_ENDPOINTS bump + name-server lands, games will stop hand-
-// picking and this comment can be retired.
-// Revisit when: name-server lands or MAX_ENDPOINTS > 32.
-const SPROUTY_ENDPOINT: u32 = 15;
+/// Sprouty's window input endpoint. Games sit at the top of the now-64-wide
+/// endpoint space (Tree=61, Worm=62, Sprouty=63), deliberately above the
+/// boot-service band (14..=33). Sprouty's endpoint has collided repeatedly
+/// as the low band filled in — a worked example of why ad-hoc `const u32`
+/// endpoints need the structural fix in ADR-018:
+///   - 22 aliased POLICY_QUERY_ENDPOINT.
+///   - 23 aliased POLICY_RESP_ENDPOINT; the kernel hardcodes a "only the
+///     policy service may write to ep 23" check in handle_write, so the
+///     compositor's Welcome reply got -EPERM and sprouty blocked forever
+///     on recv_verified.
+///   - 15 looked free, but terminal-window (auto-started) opens its front
+///     layer on 15 and drains the shared per-endpoint queue, stealing
+///     sprouty's routed input.
+/// 63 is at the top of the space, clear of every auto-started service.
+/// Revisit when: ADR-018's endpoint reservation table lands — hand-picked
+/// game endpoints move under manifest-declared reservations.
+const SPROUTY_ENDPOINT: u32 = 63;
 
 /// TUNING: physics tick interval in kernel ticks (1 tick = 10 ms at
 /// 100 Hz). 3 → 30 ms → 33 FPS — first game past ping's 20 FPS, first

user/tree/src/main.rs

@@ -46,7 +46,18 @@ mod sprites;
 
 use game::{Board, RevealOutcome, State};
 
-const TREE_ENDPOINT: u32 = 31;
+/// Tree's window input endpoint. Games sit at the top of the now-64-wide
+/// endpoint space (Tree=61, Worm=62, Sprouty=63), deliberately above the
+/// boot-service band (14..=33). That band is densely allocated and
+/// auto-started services keep growing into it: Tree originally used 31 and
+/// silently lost all input to `usb-host`, which also claims 31 and drains
+/// the shared per-endpoint queue, so the compositor's routed events never
+/// reached this game. Endpoint IDs are ad-hoc `const u32`s with no
+/// kernel-enforced one-owner-per-endpoint check; ADR-018's endpoint
+/// reservation table is the structural fix.
+/// Revisit when: ADR-018's endpoint reservation table lands — hand-picked
+/// game endpoints move under manifest-declared reservations.
+const TREE_ENDPOINT: u32 = 61;
 
 /// HID usage codes we care about. Full evdev→HID table lives in
 /// `user/virtio-input/src/evdev.rs`; we re-declare only the two we

user/worm/src/main.rs

@@ -56,19 +56,19 @@ use cambios_worm::game::{Direction, State, StepOutcome, Worm};
 
 mod render;
 
-/// Worm's IPC endpoint. The launch-plan direction is "one endpoint
-/// per app, grouped by class" (Tree=31, Worm=32, Pong=33, Mario=34),
-/// but the kernel's `MAX_ENDPOINTS` is currently a SCAFFOLDING bound
-/// of 32 — endpoint IDs are 0..=31, so 32 is out of range and
-/// `register_endpoint(32)` fails. Worm sits at 29 (free between
-/// compositor=28 and compositor-input=30) until the bound is bumped
-/// per docs/ASSUMPTIONS.md's replacement trigger ("first service that
-/// needs >32 endpoints"). When MAX_ENDPOINTS grows, move Worm to the
-/// planned slot and group by app class.
-///
-/// Revisit when: MAX_ENDPOINTS is raised kernel-side — Worm + Pong +
-/// Mario all move to their class-grouped IDs at that point.
-const WORM_ENDPOINT: u32 = 29;
+/// Worm's window input endpoint. Games sit at the top of the now-64-wide
+/// endpoint space (Tree=61, Worm=62, Sprouty=63), deliberately above the
+/// boot-service band (14..=33). The old launch-plan slots (Tree=31,
+/// Worm=32, Pong=33, Mario=34) were eaten by services that grew into that
+/// range (usb-host=31, fde-mount=32, ccid=33), so class-grouping moved to
+/// the high end. Worm previously sat at 29, which aliases hello-window's
+/// endpoint — it only worked because hello-window is disabled in
+/// limine.conf. Endpoint IDs are ad-hoc `const u32`s with no
+/// kernel-enforced ownership; ADR-018's reservation table is the
+/// structural fix.
+/// Revisit when: ADR-018's endpoint reservation table lands — hand-picked
+/// game endpoints move under manifest-declared reservations.
+const WORM_ENDPOINT: u32 = 62;
 
 /// USB HID usage codes we bind. Full evdev→HID table lives in
 /// `user/virtio-input/src/evdev.rs`; we re-declare only the ones the