fix(remote-worker): create /workspace in the leaf images

The harness execs every tool call from its sandbox working directory, which
defaults to /workspace (KAGENTI_SANDBOX_CWD, select-sandbox.ts). Neither leaf
image created it, so the worker's `bash -c` died before running anything the
caller asked for:

  bash: line 1: cd: /workspace: No such file or directory
  Command exited with code 1

and the harness reported a tool error for a sandbox that was attached, healthy,
and reachable. Found on a real VM run while proving that /turn now routes tool
calls into the pool: the exec arrived at the leaf correctly and died on the cd,
which is a more confusing failure than not arriving at all -- the pool looks
fine, the relay looks fine, and only the tool result says otherwise.

Both image definitions get it, since either can be the sandbox: Dockerfile
(multi-stage, builds the binary) and Dockerfile.runtime (packages a prebuilt
one). Owned 1001:0 and mode 775 because that is the uid/gid these images run as
under the nonroot-v2 SCC, so the agent can write in its own workspace.

This is what the Dockerfile's own comment already promised and did not deliver --
"this stage exists so the standalone demo image works on its own". It did not: as
a sandbox it failed every tool call.

Verified on hardware after rebuilding: /workspace present as
drwxrwxr-x 1001 root, all three leaves attached, and a /turn tool call's file
landed in sh-sandbox-2 while nothing appeared in the supervisor unit's PrivateTmp
namespace -- the negative half being the one that matters, since before the
routing fix that was the only place it ever appeared.

Assisted-By: Claude (Anthropic AI) <noreply@anthropic.com>
Signed-off-by: Paolo Dettori <dettori@us.ibm.com>

Author: pdettori

remote-worker/Dockerfile

@@ -30,6 +30,16 @@ FROM registry.access.redhat.com/ubi9/ubi-minimal:latest
 RUN microdnf install -y --nodocs bash coreutils-single findutils file \
     && microdnf clean all
 COPY --from=build /out/remote-worker /usr/local/bin/remote-worker
+# The harness execs every tool call from its sandbox working directory, which defaults to
+# /workspace (KAGENTI_SANDBOX_CWD, select-sandbox.ts). Without this directory the worker's
+# `bash -c` fails before running anything the caller asked for:
+#   bash: line 1: cd: /workspace: No such file or directory
+#   Command exited with code 1
+# and the harness reports a tool error for a sandbox that is otherwise healthy and attached --
+# observed on a real VM run, where the exec reached the leaf correctly and died on the cd. Owned by
+# 1001:0 because that is the uid this image runs as (gid 0, matching the nonroot-v2 SCC below), so
+# the agent can actually write in its own workspace.
+RUN mkdir -p /workspace && chown 1001:0 /workspace && chmod 775 /workspace
 # Matches the nonroot-v2 SCC deploy-incluster.sh applies.
 USER 1001
 ENTRYPOINT ["/usr/local/bin/remote-worker"]

remote-worker/Dockerfile.runtime

@@ -14,5 +14,9 @@ FROM registry.access.redhat.com/ubi9/ubi-minimal:latest
 RUN microdnf install -y --nodocs bash coreutils-single findutils file \
     && microdnf clean all
 COPY remote-worker /usr/local/bin/remote-worker
+# See the same block in ./Dockerfile: the harness execs tool calls from /workspace (the default
+# KAGENTI_SANDBOX_CWD), and without it every exec dies on `cd` before running the command, which
+# surfaces as a tool error from a sandbox that is attached and healthy.
+RUN mkdir -p /workspace && chown 1001:0 /workspace && chmod 775 /workspace
 USER 1001
 ENTRYPOINT ["/usr/local/bin/remote-worker"]