feat(adapter/grok): xAI Grok agent harness and adversarial-review backend

[potiuk]

Goal: Add xAI's Grok as a supported agent harness, following the same path as the other runtimes in the adapter registry (Codex #313, Gemini CLI #314, …). Grounds: RFC-AI-0004 Principle 3 — Vendor neutrality.

Why Grok: Grok is not in the harness list at all today, not even as a tracked extension point. Adopters who use it have no documented way to run Magpie skills, and no way to add it as an adversarial reviewer.

What "support" means — the four integration points from docs/adapters/add-a-harness.md:

1. Skill loading — a row in the agent-target registry (skills/setup/agents.md) and the relay symlinks, so the byte-identical SKILL.md files load from wherever the Grok CLI looks for skills / project instructions.
2. Action guard — a tools/agent-guard adapter if the CLI exposes a pre-tool hook, otherwise the tools/agent-isolation OS-level wrapper.
3. Spec-loop profile — a headless --cli invocation profile in tools/spec-loop/.
4. Harness declarations — the **Harness:** lines in the substrate tools that work under it.

Also in scope:

• Adversarial-review backend — a grok entry in tools/adversarial-review/src/adversarial_review/backends.py, with the same guarantees the others have: text-only prompt on stdin, read-only / plan mode, no MCP servers reachable, argv snapshot in tests/test_backends.py.
• Privacy-LLM — Grok (xAI API) is not in the default-approved set in tools/privacy-llm/models.md. Document it as an opt-in entry an adopter declares in <project-config>/privacy-llm.md with a data-residency link and approval line, so the Step 0 gate stops skills that read private lists until that is done.

To verify before implementing (not assumed here):

• Which Grok CLI to target, and whether it reads AGENTS.md / a skills directory natively.
• Whether it has a pre-tool hook API, a sandbox mode, and an approve-before-run mode (decides step 2 and the HITL mapping).
• Whether it can run headless with a read-only / plan mode and structured (JSON) output (decides step 3 and the reviewer backend).
• MCP support, and how to disable it for the reviewer backend.

Suggested order (per add-a-harness.md § Scope): registry row + relay symlinks → loop profile → guard adapter → harness declarations; the reviewer backend and privacy-llm doc can land independently.

References:

• docs/adapters/add-a-harness.md
• docs/adapters/registry.md — add Grok to the Agent harness row
• docs/vendor-neutrality.md
• Existing runtime guides for shape: docs/adapters/gemini.md, docs/adapters/codex.md

[liwenjie200543]

Claiming the reviewer-backend slice (Phase 1 of the suggested order): a grok entry in tools/adversarial-review (argv + extract + tests), the privacy-LLM opt-in documentation, and the registry row. The skill-loading row, relay symlinks, spec-loop profile and guard adapter stay out of scope for this first PR.

CLI surface verified against xai-org/grok-build@f0e3be1100ef: the single-turn -p/--single flag takes text only, so the brief goes through --prompt-file (the Copilot family); plan is a valid --permission-mode value (PermissionMode::VALID_VALUES); --output-format json emits one object whose text field carries the final answer and whose stopReason distinguishes end_turn/refusal/cancelled. Two caveats I will document next to the existing Copilot/Gemini README notes: no CLI switch to disable MCP (mcpInheritance: none is config-file only), and GROK_SESSION_ID is confirmed as the self-marker for MCP-server and hook child processes but I could not verify it for every shell-tool child from source alone.

Happy to take the remaining integration points as follow-ups once this lands.

(This note was drafted with AI assistance and reviewed before posting.)