Call the server component "server", to match dev-updater

READ BEFORE PULLING. A Managed component's service unit is named
<config key>-<component name>, so this rename moves the unit from
ai-app-backend to ai-app-server and nothing points at the old one
afterwards. Uninstall the backend component from its card *first*, while
it is still called "backend"; then pull, accept the new declaration --
.dev-updater.ron is a request, so the card shows it as pending -- and
build. The unit installs under the new name.

Two things reset rather than break, both keyed by component name: the
per-component built_from sha, and the build and runtime logs. One build
makes the sha current again.

Also drops the claim that the components list is walked in order. They
have built in parallel since 2026-08-28, so the reasoning the comment
gave -- backend first, so a failing APK leaves the phone what it had --
no longer describes what happens.

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

.dev-updater.ron

@@ -10,12 +10,12 @@
 // A built APK wins: it is the authority on what will actually install.
 label: "AI Sessions",
 
-// Walked in order, and the order is the point: the backend is built and
+// The two halves this checkout produces: the server a phone talks to, and
-// delivered first, so a failing APK build leaves the phone the APK it
+// the app that talks to it. They are built in parallel -- this list is the
-// already had rather than half of a matched pair.
+// set, not a sequence, so nothing here should be read as an order.
 components: [
     Server(
-        name: "backend",
+        name: "server",
         build: "cargo build --release",
         cwd: "server",
         // Dev Updater's own built-in service implementation, generated

AGENTS.md

@@ -82,8 +82,8 @@ repo is in PLAN.md's "Backend layout" section.
   event model mirror; `ServerConfig.kt` settings + Keystore-sealed token;
   screens in `SessionListScreen/SessionScreen/SpawnScreen/SettingsScreen`.
 - `.dev-updater.ron` — what Dev Updater is asked to do with this checkout:
-  the backend (built in `server/`, run as `service: Managed(...)`) and then
+  the server (built in `server/`, run as `service: Managed(...)`) and the
-  the APK (built in `app/`), in that order. The project it serves is the
+  APK (built in `app/`), built in parallel. The project it serves is the
   repository, not either half of it, which is why this sits at the root
   rather than in `app/`.
   `Managed` means Dev Updater supervises `ai-server` with its own built-in
@@ -92,7 +92,7 @@ repo is in PLAN.md's "Backend layout" section.
   arguments, no environment — so the two projects were maintaining one
   behaviour twice, including the OpenRC branch neither can test from a
   systemd machine.
-  Worth knowing before pressing it: **Stop** on the backend card stops the
+  Worth knowing before pressing it: **Stop** on the server card stops the
   server that a phone reaches through the tunnel, so on that phone it stays
   down until someone starts it again from Dev Updater. Dev Updater reaches
   it over its own port and is unaffected, which is what makes the button