Stop setup blocking on invisible sbx confirmation prompts

sbx skills import prompts before overwriting each skill already in the shared
store. setup called it with stdout and stderr redirected and stdin left
attached, so on any second run the prompt was invisible and setup hung
indefinitely partway through installing the Claude configuration.

sbx rm prompts the same way, which would have blocked --replace and remove
once a sandbox was in use.

Both now pass --force and read from /dev/null. This is the third instance of
the pattern after sbx secret set, which cancelled silently and still exited 0,
so a test now asserts at the source level that every prompting subcommand is
invoked non-interactively. The test was confirmed to fail when either --force
is removed.

tasks/ai/sbx

@@ -660,7 +660,10 @@ install_sandbox_claude_config() {
 
     # The store is shared by every sandbox, so this seeds all of them at once.
     if [[ -d "$CLAUDE_HOME/skills" ]]; then
-        sbx skills import >/dev/null 2>&1 ||
+        # --force is mandatory: the store is shared, so a second setup finds
+        # skills already there and prompts per skill. With output redirected
+        # the prompt is invisible and setup hangs on stdin forever.
+        sbx skills import --force </dev/null >/dev/null 2>&1 ||
             printf 'Could not import skills into the shared store.\n' >&2
     fi
 
@@ -909,7 +912,7 @@ setup_command() {
     if sandbox_exists; then
         if [[ "$replace" == true ]]; then
             printf 'Removing existing sandbox %s...\n' "$SANDBOX_NAME"
-            sbx rm "$SANDBOX_NAME"
+            sbx rm --force "$SANDBOX_NAME" </dev/null
         else
             printf 'Using existing sandbox %s.\n' "$SANDBOX_NAME"
         fi
@@ -1042,7 +1045,7 @@ remove_command() {
     load_config
 
     if sandbox_exists; then
-        sbx rm "$SANDBOX_NAME"
+        sbx rm --force "$SANDBOX_NAME" </dev/null
     fi
 
     rm -rf "$REPO_CONFIG_DIR"