fix(sandbox): fail closed when namespace isolation cannot be applied

[cursor]

Bug and impact

With sandbox.enabled = true (the documented config.example.toml default), ShellClaw claimed Linux mount/network/PID namespace isolation for the shell tool. On a typical non-root install, unshare(CLONE_NEWNS | CLONE_NEWNET | CLONE_NEWPID) returns EPERM and the return value was ignored. The child then execl("/bin/sh", ...) on the host network.

Trigger: copy the example config, run as a normal user, and have the agent execute a command with no path tokens (allowlist phase-2 skips URLs), for example curl http://169.254.169.254/ or a connect to a host loopback service. The command succeeds even though the operator enabled the sandbox.

This is distinct from open PRs #66/#68/#74 (path/symlink/Landlock filesystem escapes).

Root cause

setup_child_process in src/sandbox/sandbox.c called unshare(...) without checking the result and never entered a user namespace, which unprivileged processes need before they can unshare net/mount/pid.

Fix

1. Try the privileged unshare first (root).
2. On failure, unshare(CLONE_NEWUSER), write setgroups/uid_map/gid_map, then unshare net/mount/pid.
3. If isolation still cannot be applied, _exit(123) and sandbox_exec returns -1 (fail-closed) instead of running on the host netns.

Validation

• CI=true make test_sandbox (-Werror)
• Existing sandbox tests plus test_network_namespace_blocks_host_loopback (host loopback listener must not be reachable from inside sandbox_exec)
• Same tests under gcc ASan/UBSan