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
-// delivered first, so a failing APK build leaves the phone the APK it
-// already had rather than half of a matched pair.
+// The two halves this checkout produces: the server a phone talks to, and
+// the app that talks to it. They are built in parallel -- this list is the
+// 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