split-plan: render the real task map and export it as a durable gate-2 artifact (unblocks reachy-mini-cli workforce runs)

[OriNachum]

What happened (concrete run evidence)

During the runtime-senses-75-78 workforce run in reachy-mini-cli (frame + plan slug runtime-senses-bounded-rules-goto-lane-75-78, 11 tasks / 5 waves), the operator asked at gate 2 to see the full implementation split before approving. The assign-to-workforce skill's split-plan subcommand rendered only a placeholder table — every row read:

| t1 | 1 | (see plan export for summary + acceptance criteria) | subagent | cheaper/faster | TDD-scoped task; ... |

The plan state ALREADY holds everything the table points away from: per-task summaries, acceptance criteria, operator instructions (devague plan instruct), dependencies, and coverage targets. The operator had to have the map hand-rendered in conversation, then asked for it to be written to a file — we hand-authored docs/plans/2026-07-18-runtime-senses-75-78-split.md in reachy-mini-cli (a full task/wave/owner/worktree/files table + per-task content + run mechanics + carried risks) — and asked that this become part of the flow rather than a per-run improvisation.

The ask

Make the gate-2 split map first-class in the assign-to-workforce leg:

1. Inline real task content. split-plan should render each task's summary, acceptance criteria, and instruction from the live plan state (devague plan waves --json + task records) instead of (see plan export for summary + acceptance criteria). The generic scope note and cheaper/faster placeholder likewise replaced by whatever annotation exists (or an explicit — propose — marker where the operator/agent must fill one in).
2. Per-task owner/model annotations. A deterministic way to record the approved assignment per task (agent type, model, worktree branch) — either a devague plan assign <tN> --owner <text> move on plan state, or a documented annotation block the skill reads/writes. devague stays non-orchestrating (Expose plan dependency waves as deterministic metadata, not orchestration #20): it records the assignment as data; the operator still performs the fan-out.
3. Durable companion artifact. Support exporting the approved split next to the exported plan (e.g. docs/plans/<created-date>-<slug>-split.md), so gate 2's decision survives in history the way the spec (gate 1) and plan already do. Today the spec and plan are committed artifacts but the split — the one implementation-stage human decision — lives only in the conversation.

Acceptance criteria

• split-plan on a converged plan prints every task's real summary + acceptance criteria + instruction, grouped by wave, with no placeholder text.

• The approved per-task owner/model/worktree assignment is recordable as deterministic plan-adjacent state (no LLM calls in-CLI, per Expose plan dependency waves as deterministic metadata, not orchestration #20) and renders into the split output.

• A --write (or equivalent) produces the committed companion artifact next to the exported plan-md; re-running overwrites in place (same dated filename convention as spec/plan exports).

• The reference example to compare against: reachy-mini-cli docs/plans/2026-07-18-runtime-senses-75-78-split.md (hand-authored during this run; shape = ownership table + per-task content + run mechanics + carried risks).

• reachy-mini-cli (Claude)