Give each component build modes and a settings sheet

A component now declares its ways of being built in one list -- `modes:
["release", "debug"]`, the first the default -- and every command it runs
is handed the mode as its last argument, so a project whose script takes
`release` or `debug` names that script once. A field may instead be
written per mode, which is the escape hatch for the commands that cannot
take the word: cargo takes `--release` or nothing, and its profile for
the unoptimised build is called `dev` while the directory it writes is
called `debug`, so no single word serves as both the flag and the path.
A command written per mode is not handed the word as well; it already is
the answer, and a stray argument to a service binary is a process that
will not start.

One list rather than gathering names from whichever fields happened to
mention them is what makes a mode missing from one part unsayable: every
per-mode map is checked against it, so a gap is named rather than
resolved to some other mode's command.

Which mode to build in and whether to strip are the build machine's --
there is one checkout and one set of outputs, so a per-device mode would
have two phones rebuilding over each other silently. Which of the
finished builds a phone installs stays that phone's. Neither choice is
part of the acceptance gate, so both have to be carried across the
components list being rewritten, by acceptance and by the self entry's
startup reconciliation alike; without the second a mode chosen for this
server's own component would not survive the restart that applies it.

A mode switch moves no commit, so `builtMode` is recorded beside
`builtFrom`. Without it a component built in debug and switched to
release reads as current and serves the debug build for ever -- and for
an APK nothing else notices, because the "never built at all" check finds
any variant under the component's directory.

Each component card gains a settings sheet behind a gear at the row's
right-hand end, holding the mode, which build to install, strip, and an
Enrol button. The variant picker moved into it: on the card the two read
as one choice, both saying debug and release, and they are not. The row's
text is now bounded and truncates, so a long status can no longer push
the log and settings buttons off the edge.

`enroll:` is a declared command whose one line of stdout is a URL for the
phone to open after installing -- generic on purpose, run per press since
such a link is one-shot and carries a credential, and in the acceptance
gate because it runs on the build machine.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

test-projects/service-and-app/.dev-updater.ron

@@ -20,6 +20,13 @@ resources: Ron("resources.ron"),
 components: [
     Server(
         name: "daemon",
+        // Two modes, declared once. Both commands are written *once*
+        // and handed the mode as their last argument, which is the
+        // ordinary way -- Dev Updater's own declaration covers the other
+        // way, where a command cannot take the word and is written per
+        // mode instead. Between the two fixtures both paths are
+        // exercised. `release` first, since the first is the default.
+        modes: ["release", "debug"],
         build: "./build-daemon.sh",
         // Managed, so Dev Updater's own service script drives it and this
         // project needs no systemd or OpenRC knowledge of its own. The

test-projects/service-and-app/build-daemon.sh

@@ -6,16 +6,31 @@
 # seconds. A card with one instant component and one slow one is how you see
 # whether the per-component timings and the concurrent build really are per
 # component.
+#
+# It takes the build mode as its one argument, so that this fixture
+# exercises a component with more than one way of being built. `release`
+# is deliberately the slow one, which is both what a real optimised build
+# is and what makes a mode switch visible on the card: a bar that takes
+# eight seconds and one that takes two.
 set -eu
 
-STEPS=8
+MODE="${1:-release}"
+case "$MODE" in
+release) STEPS=8 ;;
+debug) STEPS=2 ;;
+*)
+    echo "unknown build mode: $MODE (expected release or debug)" >&2
+    exit 2
+    ;;
+esac
+
 i=0
 while [ "$i" -lt "$STEPS" ]; do
     i=$((i + 1))
     echo "@@progress $i/$STEPS"
-    echo "==> Pretending to compile part $i of $STEPS"
+    echo "==> Pretending to compile part $i of $STEPS ($MODE)"
     sleep 1
 done
 
 chmod +x ./serve.sh
-echo "==> Daemon ready"
+echo "==> Daemon ready ($MODE)"

test-projects/service-and-app/serve.sh

@@ -7,12 +7,27 @@
 # that the directory exists to be shown in the dialog. Its *log* is not
 # written here: a managed service's output is captured by Dev Updater's
 # service script, which is what the runtime log tab reads.
+#
+# Takes the build mode as its one argument, ahead of whatever subcommand
+# the service contract appends -- which is how a command written once
+# learns which mode it is running in. It ticks at a different rate in
+# each, so that a mode switch is checkable from a phone: the runtime log
+# is the only place the difference shows.
 set -eu
 
+MODE="${1:-release}"
+case "$MODE" in
+release) INTERVAL=10 ;;
+debug) INTERVAL=2 ;;
+*)
+    echo "unknown mode: $MODE (expected release or debug)" >&2
+    exit 2
+    ;;
+esac
 DATA="${XDG_DATA_HOME:-$HOME/.local/share}/dutest-service"
 mkdir -p "$DATA"
 
-echo "started at $(date -Is), writing to $DATA"
+echo "started at $(date -Is), writing to $DATA, ticking every ${INTERVAL}s in $MODE"
 count=0
 while true; do
     count=$((count + 1))
@@ -20,5 +35,5 @@ while true; do
     # Colour, so the runtime log tab has escapes to render too -- the same
     # reason breakable/build.sh writes them.
     printf 'tick \033[1;32m%s\033[0m -- still here\n' "$count"
-    sleep 10
+    sleep "$INTERVAL"
 done