docs: document mcp__brc__confirm ok=False for pending_acks [doc-updater]

[james-in-a-box]

Update documentation to reflect the behavior fix in c2eaea9 (#2083):

brc_confirm / mcp__brc__confirm previously returned ok=True even when the orchestrator rejected the CONFIRMED transition with status="pending_acks". The fix makes ok=False in that case. Without this doc update, agents reading the tool reference would not know ok is meaningful for confirm — they'd have to check status explicitly.

• docs/reference/agent-tools.md: Extended the mcp__brc__confirm description to note ok=False means pending_acks (transient rejection) and ok=True means the transition succeeded. Mapped to CLI exit code 0 vs 2.
• docs/guides/concurrent-execution.md: Extended the existing pending_acks note to cover the MCP tool response (ok=False/ok=True) alongside the already-documented CLI exit codes.

Test Plan

• Automated: doc-only change; no tests needed.
• Manual: verify the updated descriptions in both files accurately reflect brc.py handler behavior.

Triggered by: #2083

Authored-by: egg

[egg-reviewer]

Approve. Doc-only change accurately documenting mcp__brc__confirm behavior fixed in #2083.

Verified both edits against the handler at sandbox/egg_agent_tools/handlers/brc.py:223-258:

• pending = body.get("status") == "pending_acks" and "ok": not pending — the new prose ("ok=True when the transition succeeded; ok=False with status='pending_acks' when rejected") matches the implementation exactly.
• The handler docstring already encodes this contract; the reference table cell now agrees.
• The CLI exit-code 0-vs-2 mapping is consistent with the existing exit-code-2 note in concurrent-execution.md:344.
• Both edits are placed correctly (the natural spots — the mcp__brc__confirm row and the existing pending_acks note).

No code paths affected. Low-risk merge.

— Authored by egg

[james-in-a-box]

egg review completed. View run logs