feat(v5): chief-loop parallel ticket execution via isolated worktrees

[mildronize]

Summary

User asked whether chief-loop could build multiple tickets at once. Went through a
full /grilling session before implementing — decisions made there, now built.

Design (from the grill)

• Default stays sequential — today's behavior, unchanged, zero risk for existing
  users.
• Opt in via parallel (asks the concurrency limit at Entry Confirmation, same
  gate mode already uses) or parallel:<N> (skips asking). Combines freely with the
  standard/strict mode argument: /chief-loop, /chief-loop strict,
  /chief-loop parallel:3, /chief-loop strict parallel:3.
• chief-build stays caller-agnostic. It gained a "Working directory" note
  (normally its own checkout; chief-loop can tell it to operate and commit in a
  specific git worktree instead) but the build recipe itself never changes based on
  where it runs. Worktree lifecycle (create/merge/remove) is entirely chief-loop's
  job, never chief-build's — matches chief-build's existing "no different behavior
  between invocation surfaces" principle.
• Streaming pool, not batches. A ticket's worktree branches off the story branch's
  current tip at the moment it starts (picking up whatever earlier parallel tickets
  already merged, reducing conflict odds as a round progresses). The instant a pooled
  ticket finishes and merges back, the freed slot is immediately refilled from the
  recomputed frontier — never waiting for the rest of the pool. Waiting for a whole
  cohort before refilling would have quietly reintroduced the fixed-size batching v5
  deliberately dropped from v4.
• Merge conflicts reuse "Handling Ambiguity." Reconciling a worktree branch back
  and hitting a conflict routes through the same mechanism chief-loop already uses
  for /chief-build blockers, rather than a second parallel mechanism — a throwaway
  agent looks at both sides, chief-loop decides, the resolution is documented in
  that ticket's report.

Changes

• chief-loop: new Concurrency argument axis, #### Parallel Execution subsection
  under The Loop with the full pool mechanics, Handling Ambiguity extended to cover
  merge conflicts, Rules extended.
• chief-build: new "Working directory" note — accepts an optional directory override
  from its caller; nothing else about its behavior changes.
• chief-explain: skill-family table row updated to mention the new argument.

Out of scope

chief-autopilot untouched — it stays standard-only/sequential-only per its existing
"no argument to change this" design from the previous PR. Not asked for here.

🤖 Generated with Claude Code