### Summary
Sandboxed requester sessions could reach host-side ACP session initialization through `/acp spawn`.

OpenClaw already blocked `sessions_spawn({ runtime: "acp" })` from sandboxed sessions, but the slash-command path initialized ACP directly without applying the same host-runtime guard first.

### Affected Packages / Versions
- npm package: `openclaw`
- Affected versions: `<= 2026.3.2`
- Patched version: `>= 2026.3.7`

### Details
ACP sessions run on the host, not inside the OpenClaw sandbox. The direct ACP spawn path in `src/agents/acp-spawn.ts` already denied sandboxed requesters, but `/acp spawn` in `src/auto-reply/reply/commands-acp/lifecycle.ts` called `initializeSession(...)` without first applying the same restriction.

In affected versions, an already authorized sender in a sandboxed session could use `/acp spawn` to cross from sandboxed chat context into host-side ACP runtime initialization when ACP was enabled and a backend was available.

### Fix Commit(s)
- `61000b8e4ded919ca1a825d4700db4cb3fdc56e3`

### Fix Details
The fix introduced a shared ACP runtime-policy guard in `src/agents/acp-spawn.ts` and reused it from the `/acp spawn` handler in `src/auto-reply/reply/commands-acp/lifecycle.ts` before any ACP backend initialization. Regression coverage was added in `src/auto-reply/reply/commands-acp.test.ts` to prove sandboxed `/acp spawn` requests are rejected early, while existing ACP spawn behavior for non-sandboxed sessions remains unchanged.

### Release Process Note
Patched version is pre-set to `2026.3.7` so the advisory can be published once that npm release is available.

Thanks @tdjackey for reporting.

CWE-284 Improper Access Control

CWE-693 Protection Mechanism Failure