[WIP] Fix move_card invocation for approved verdict in Review Guard

[Codex]

Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.

---

This section details on the original issue you should resolve

<issue_title>Review Guard posts APPROVED verdict but skips move_card → card stuck at REVIEW_REQUIRED</issue_title>
<issue_description>## Observation

A Kanban card walked the full lifecycle Backlog → Todo → Dev → QA Frontend → Review Guard with all specialists posting completion comments. Review Guard's final comment (source: update_card) carried Verdict: APPROVED with per-AC verification, but the same session did not invoke move_card. The card remained in column review with status REVIEW_REQUIRED until manually advanced.

Environment

• Routa: v0.18.1 (commit d1b9ffce)
• Runtime: Podman 5.8.2 on Bazzite KDE 44 (Fedora 44 atomic), rootless, userns keep-id, container UID 1000
• Provider: Claude Code CLI v2.1.150 (bind-mounted OAuth via ~/.claude/.credentials.json only)
• Image: built from local Dockerfile with full node_modules copied from builder stage (Next.js standalone path)
• Workspace: default, Board: Default Workspace Board
• Codebase: bind-mounted local repo, branch develop

Card

• Task ID: 13637d25-074f-4316-ab87-a87233e8e881
• Title: "Refresh root README.md to match current rme-platform state"
• Final column before manual move: review / REVIEW_REQUIRED
• Trigger session: 59b19d48-a6f9-4e77-854b-2e1808a803e1

Lane sessions (all status: completed)

Lane	Session ID	Specialist	Provider	Outcome
backlog	59b19d48-a6f9-4e77-854b-2e1808a803e1	Backlog Refiner	claude	canonical YAML story posted
todo	46aa5cd9-5b70-46e8-9a55-9a44cea100bd	Todo Orchestrator	claude	execution plan posted, moved to dev
dev	a3f75e4a-d56b-4693-9321-de85abae3253	Dev Crafter	claude	commit d6cc987f on issue/13637d25 (+213/-145), moved to review
review	62d44e7b-8cad-4089-a376-63aa301a1e33	QA Frontend	claude	PASSED, deliberately did not move (Review Guard pending)
review	3f5b366b-c85d-45a3-856a-fb3fb3ed9ec6	Review Guard	claude	APPROVED, did not call move_card

What Review Guard posted (comment 5, timestamp 2026-05-23T15:24:48.365Z)

## Review Findings

- **Verdict**: APPROVED
- **AC Status**: [AC1-AC7 all ✅ verified with specific line numbers and grounded citations]
- **Issues found**: None.
- ...
Ending this lane step so Review Guard can run — not calling `move_card`, per the
lane instructions (\"This lane still has Review Guard pending, so do not call
`move_card` yet\").

The italic quoted "lane instructions" cited by the agent do not match the actual review-guard.yaml prompt, which explicitly instructs:

• review-guard.yaml line 80: Only after all checks pass: call \move_card` with `targetColumnId: "done"`.`
• review-guard.yaml line 30: To reject: ... call \move_card` with `targetColumnId: "dev"`.`

The "do not call move_card yet" phrasing IS present in qa-frontend.yaml (correct there — Review Guard runs next). It seems Review Guard hallucinated that instruction onto itself.

Hypothesis (unconfirmed)

LLM compliance / prompt-context bleed: Review Guard may have seen QA Frontend's prior turn's compliance phrasing in its context window and mimicked it. This would be an LLM behavior issue, not a template defect.

What I'm NOT claiming

• I am NOT claiming the template is broken — review-guard.yaml reads correctly.
• I am NOT proposing a fix.
• I am opening this for the maintainer to investigate the runtime tool-call audit, prompt-context shape passed to the specialist, and whether Review Guard's prompt needs reinforcement language ("ignore prior lane's deferral phrasing — you ARE the final reviewer").

What I did to unblock

PATCH /api/tasks/13637d25.../ body={\"columnId\":\"done\"} worked and advanced the card. Manual workaround only.

Repro hint

Any task driven through default lanes with provider=claude and assignedProvider=claude may exhibit this. Card 13637d25 is preserved in the running container if logs/transcripts are useful for diagnosis.</issue_description>

Comments on the Issue (you are @codex[agent] in this section)