fix(authz): gate the cli-tools status and skills execution routes to LOCAL_ONLY

[diegosouzapw]

Fixes two privately reported advisories of the same class as /api/acp/agents (GHSA-hf57):
GHSA-35fw-cv32-2373 and GHSA-jx89-f37j-pq89. A route whose handler chain spawns a host
process sat on Tier 3 MANAGEMENT only, and requireManagementAuth() waives auth under
requireLogin=false. Hard Rules #15/#17 require the LOCAL_ONLY gate, which runs on the stamped
real peer before any auth check.

GHSA-35fw — 14 cli-tools routes

All reach getCliRuntimeStatus() → locateCommand() → runProcess("sh", ["-c", 'command -v -- "$1"']) → spawn(),
exactly like the six siblings already gated (forge / grok-build / jcode / qwen / omp / letta):

• all-statuses, status
• claude / cline / codewhale / codex / crush / deepseek-tui / droid / kilo / openclaw / pi / smelt -settings
• detect — missed by the advisory, and the heaviest: detectAllTools() runs execFile(binary, ["--version"]) and execFile("which") per tool.

The advisory's precondition is also narrower than stated: a fresh install is only open from
loopback, so the realistic exposure is an instance explicitly running with requireLogin=false.

GHSA-jx89 — skills install + executions

POST /api/skills/install stores handlerCode verbatim as the handler with no allowlist, so a
value equal to a built-in name (execute_command, eval_code) aliases the real sandboxed
built-in; POST /api/skills/executions then runs it. The sandbox is a genuine container
(--network none, --cap-drop ALL, read-only, allowlisted images), but the spawn is transitive,
so the 6A.8 route-guard source scan never saw it.

Change

• 16 exact entries in LOCAL_ONLY_API_PREFIXES, mirrored in SPAWN_CAPABLE_PREFIXES (no manage-scope bypass).
• The 16 route dirs added to check-route-guard-membership.ts roots, so the gate now enforces them.
• No blanket /api/cli-tools/ prefix — apply, backups, config, guide-settings,
  hermes-agent-settings, keys, logs, openclaw/auto-order and codex-profiles do not spawn
  and remote dashboards use them.
• ROUTE_GUARD_TIERS.md, x-loopback-only in openapi.yaml, changelog fragment.

Functional trade-off (same one already accepted for grok/forge/jcode/qwen): a dashboard served
through a tunnel no longer shows the CLI Tools status badges, and skill execution history is
loopback/LAN only.

Validation (TDD)

Check	Result
New route-guard-cli-tools-settings-local-only + route-guard-skills-execute-local-only on the tip	red
Route-guard, authz and membership suites after the fix	422 / 422
check:route-guard-membership	OK — 82 routes in 24 roots, 0 gaps
check:openapi-security-tiers	PASS (the traffic-inspector warnings are pre-existing)
typecheck:core, check:docs-sync, prettier	clean
eslint	clean under the repo's suppressions file

Two existing negative controls pointed at routes that turn out to spawn
(/api/cli-tools/all-statuses, /api/skills/install). They were replaced, not removed, with
routes that genuinely do not spawn (/api/cli-tools/config, /api/skills/marketplace,
/api/skills/skillssh/install), so the non-over-gating assertions still hold.

⚠️ base-red inherited: #12732 — failures outside the route-guard suites come from the tip.