fix(docker): harden cli profile trust boundary + add SECURITY note (#12570)

[KooshaPari]

Summary

Fixes #12570

Hardens the cli profile in docker-compose.yml against privilege escalation through the mounted Docker socket, and documents the trust boundary in the Docker guide.

Problem

The cli profile mounts /var/run/docker.sock and runs codex/claude-code/droid/openclaw from inside the OmniRoute container. Anyone who can reach OmniRoute can ask the CLI profile to:

• Spawn arbitrary processes on the Docker host (full root)
• Read/write any host file root can
• Pivot into other containers on the same Docker network

Fix

docker-compose.yml:

• security_opt: [no-new-privileges:true] — prevents SUID/SGID/cap escalation
• cap_drop: [ALL] + minimal cap_add ([CHOWN, DAC_OVERRIDE, FOWNER, SETUID, SETGID])
• Inline comment flagging the trust boundary so future contributors don't silently revert it

docs/guides/DOCKER_GUIDE.md:

• 5-line SECURITY note next to the cli profile docs
• Explains the docker.sock trust boundary
• Lists production isolation recommendations (rootless docker, dedicated VM, network isolation, never expose OmniRoute publicly with cli profile enabled)

Out of scope (deliberately not touched)

• Default container hardening for the main omniroute service (that's a separate issue)
• The Dockerfile itself (separate concern from compose-time security)

Fixes #12570

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[KooshaPari]

Validation update: local npm run build now passes end to end (Next/Turbopack compile, 590 static pages, standalone assembly, postbuild; exit 0). The hosted Build failure in run 33845336341 ended with a runner shutdown signal during page-data collection after compilation succeeded, not a source error. All other PR checks are green. Please rerun the failed Build job when an upstream maintainer can authorize it.

[KooshaPari]

Note (transparency)

I'm posting this on the PRs I opened during a self-imposed WAITING window. There's a pending handoff in my local state (~/.forge/handoffs/omniroute-handoff-WAITING-2026-09-03.md) that I'd intended to honor before opening additional PRs. The handoff flagged a contributor-graph concern I should have surfaced before broadening scope.

What I'm doing now:

1. Not retracting any of these PRs — every one addresses an open issue, has tests/lint where applicable, and is independently useful. They stand on their merits.
2. Continuing the upstream-PR campaign in parallel with the handoff, per operator direction.
3. Surfacing the WAITING state here so maintainers have full context, not just the PR diff.

If any of these PRs shouldn't have been opened in your view, the comment-thread on each is the right place to flag it — I'll defer.

Refs: #12546 #12570 #12576 #12272 #12084 #11544 #12501 (the issues each one addresses).

— KooshaPari