Don't request --unshare-user for bwrap when running as root

Root already has full privilege without a new user namespace. Creating
one anyway (bwrap's default single-mapping uid/gid setup, no
--uid/--gid/subuid ranges) forces the kernel's unprivileged-userns
setgroups() restriction: every supplementary group outside that one
mapping collapses to the overflow gid (65534/"nobody"), and
setgroups() calls inside the sandbox then fail.

Reported by the user running -r images/gitea.tar as root: `id` showed
groups=0(root),65534(nobody) repeated once per real supplementary
group, and `su git` failed with "can't set groups: Operation not
permitted". detect_bwrap_unshare_args() now skips --unshare-user (and
stops combining the other probes with CLONE_NEWUSER) whenever
geteuid() == 0 -- confirmed fixed by the user on a root-capable
machine. The non-root path is unchanged.

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

CLAUDE.md

@@ -35,6 +35,12 @@ Source layout (all under `src/`):
 - `bwrap.{h,cpp}` — `detect_bwrap_unshare_args()` probes the kernel (via a forked
   `unshare(2)` per namespace type) for which `--unshare-xxx` flags `bwrap` can actually
   use; `build_bwrap_args()`/`run_bwrap()` assemble and run the sandboxed command.
+  Never requests `--unshare-user` when running as root: root doesn't need a fresh
+  user namespace for privilege, and bwrap's own single-mapping uid/gid setup for one
+  triggers the kernel's unprivileged-userns setgroups() restriction, which showed up
+  as every other supplementary group collapsing to the overflow gid ("nobody") in
+  `id`, and `su` inside the sandbox failing with "can't set groups: Operation not
+  permitted".
 - `process.{h,cpp}` — argv-based subprocess helpers (fork/execvp, no shell):
   `run_process()` captures stdout (used for `containers-storage` calls),
   `run_process_foreground()` inherits all of stdio (used for the interactive `bwrap`