fix(sandbox): don't denyWrite read-only mounts; fix verify service label

[kskim9]

Summary

Two bugs surfaced during a fresh setup with RUNTIME=sandbox on macOS (Seatbelt via @anthropic-ai/sandbox-runtime 0.0.42).

1. Sandbox: read-only mounts blocked nested writable subdirs (P0)

@anthropic-ai/sandbox-runtime's schema documents denyWrite as "taking precedence over allowWrite" (also visible in the installed copy at node_modules/@anthropic-ai/sandbox-runtime/dist/sandbox/sandbox-config.js:109).

The previous code pushed every read-only mount to both allowRead and denyWrite, intending to "enforce read-only at srt level". But because denyWrite wins on conflict, this blocked writes to any subdirectory of a read-only mount — including the group's own workspace.

In the main-group default config:

• projectRoot (e.g. ~/claudeclaw) is mounted read-only
• groupDir (e.g. ~/claudeclaw/groups/slack_main) is mounted read-write inside it

The agent crashed on first run with:

EPERM: operation not permitted, mkdir '/Users/.../claudeclaw/groups/slack_main/memory'

…because denyWrite=projectRoot overrode allowWrite=groupDir. The message loop retried 5 times then gave up — silent fail from the user's perspective.

Fix: drop the denyWrite.push() for read-only mounts. The sandbox is allow-list-based; paths absent from allowWrite are already implicitly denied, which enforces read-only on the parent without blocking nested writable subdirs.

This bug means any user of the sandbox runtime with the default is_main=true group hits it the moment the agent tries to create its memory dir.

2. setup: verify and service disagreed on the service label

setup/service.ts derives the launchd/systemd label from basename(process.cwd()), but setup/verify.ts used basename(DATA_DIR). Since DATA_DIR resolves to <STATE_ROOT>/data, the two scripts computed different labels:

Script	Label
setup/service.ts	com.claudeclaw.<project-dirname>
setup/verify.ts	com.claudeclaw.data (always)

Result: verify always reported SERVICE: not_found even when the service was running, producing STATUS: failed on the final setup step.

Fix: use STATE_ROOT instead of DATA_DIR in verify.ts so the two scripts agree.

Test plan

• Fresh setup with RUNTIME=sandbox on macOS, single Slack DM as main group — confirmed EPERM reproduces on main and is gone after the patch
• Captured the generated data/sandbox-settings/*.json to verify denyWrite no longer contains the project root
• Confirmed agent successfully creates groups/<folder>/memory/, completes a query, and posts to Slack
• npx tsx setup/index.ts --step verify now reports SERVICE: running / STATUS: success against a running launchd service
• Container runtime regression test (untested — I only have sandbox configured locally; container path doesn't go through buildSandboxSettings so no behavior change is expected)