fix(docker): the image's gateway run keeps the root profile, and a leading -p reaches hermes

Inside the s6 image a bare `gateway run` (the image's CMD) redirects to the
supervised slot of the current profile. The profile pre-parse applied the
sticky active_profile first, so after `hermes profile use <name>` (or a
dashboard profile switch) every container boot started that named slot:
the one the boot reconciler had just registered down, because a started
named slot is a second gateway beside the multiplexer. The redirected run
now keeps the root identity like any supervised slot (#74872);
--no-supervise keeps the foreground behaviour that follows active_profile.

The obvious workaround, pinning the CMD to `-p default gateway run`,
restart-looped the container: main-wrapper.sh probes `command -v "$1"`,
and `command -v -p` parses -p as an option to `command` and succeeds, so
the wrapper exec'd "-p". A leading flag now always goes to hermes.

docker/main-wrapper.sh

@@ -82,10 +82,18 @@ if [ $# -eq 0 ]; then
     drop hermes
 fi
 
-if command -v "$1" >/dev/null 2>&1; then
-    # Bare executable — pass through directly.
-    drop "$@"
-fi
+# A leading flag is a hermes global option (`-p <profile> gateway run`), never an executable:
+# `command -v -p` parses -p as an option to `command` itself and succeeds, so the wrapper exec'd
+# "-p" and the container restart-looped.
+case "$1" in
+    -*) ;;
+    *)
+        if command -v "$1" >/dev/null 2>&1; then
+            # Bare executable — pass through directly.
+            drop "$@"
+        fi
+        ;;
+esac
 
 # Hermes subcommand pass-through.
 drop hermes "$@"