Pre-approve J5 tools on OpenCode threads #265

Where it breaks. An OpenCode thread gets the t3-code MCP server, but openCodePermissionRules (OpenCodeAdapterV2.ts) sends every MCP tool through its catch-all rule. In approval-required, auto, and auto-accept-edits, propose_crew raises a native OpenCode approval before the roster gate. Under approval policy never with a read-only or workspace-write sandbox (a saved persona's policy), it is refused outright, and the J5 tools are hidden, so that Captain cannot propose a Crew at all. Code-derived (#233).

What should change. A J5-owned j5OpenCodePermissionRules (apps/server/src/j5/a2a/mcp/openCodeToolApproval.ts) turns j5PreapprovedTools(policy) into allow rules for t3-code_<tool>. One spread appended before openCodePermissionRules returns adds them; it has to come last because OpenCode's rules are last-match-wins (verified against OpenCode v1.15.13). Task child sessions inherit the parent's rules, so no second spread. Record it in FORK.md.

Tests to ship. A per-policy parity test over the shared policy matrix: the effective (last-matching) rule is allow exactly for the shared set; worktree handoff, preview, and scheduling keep OpenCode's verdict; child sessions carry the allows.

Done when. An OpenCode Captain's propose_crew reaches the roster gate without an OpenCode prompt in every runtime mode, and docs/user/personas.md drops OpenCode from the harnesses that still prompt before the roster gate.

Part of #233.