Parallel sub-agent strategy for execute stage

## Context

Split from #57. The execute stage currently processes plan steps sequentially. For large migrations (50+ steps), parallel sub-agents could significantly reduce execution time.

## Problem

Each plan step (or group of steps) could run as a separate sub-agent. Each sub-agent handles one step from `implementation.md` — reads the target file, applies transformations, writes it back.

Sub-agents working in parallel need a git merge strategy. Several approaches exist, each with trade-offs:

### Option A: Disjoint files on the same branch

Steps in `implementation.md` are one-file-per-step, so conflicts are unlikely if steps are partitioned correctly. Sub-agents claim non-overlapping file sets and commit directly to the migration branch.

**Pros:** Simple, no merge step, natural commit history
**Cons:** Shared files (pom.xml, application.properties, config files) are touched by multiple phases — these must be serialized or handled specially

### Option B: Branch-per-sub-agent

Each sub-agent works on a separate branch. Results are merged back into the main migration branch after all sub-agents in a phase complete.

**Pros:** Full isolation, no conflicts during execution
**Cons:** Merge conflicts possible (especially config files), complex merge orchestration, noisy git history

### Option C: Phase-level parallelism only

Steps within a phase run in parallel (they typically touch disjoint files). Phases remain sequential (build gate enforces this anyway). Shared config files (pom.xml, application.properties) are handled by a dedicated "config step" at the start of each phase, before sub-agents fan out.

**Pros:** Leverages the existing phase structure, build gates remain sequential, shared files handled deterministically
**Cons:** Limited parallelism (only within a phase, not across phases)

## Open questions

- How does the sub-agent strategy interact with context window limits? (Sub-agents get a fresh context per step)
- How are merge conflicts resolved if two steps touch the same file? (e.g. both adding imports to the same Java file)
- Should the orchestration live in the skill (goose sub-agents) or in the harness/controller (AgentRun per step)?
- How does partial failure work — if 3 of 10 sub-agents fail, do we abort the phase or commit the successful ones?

## References

- Parent: #57
- Related: #54

Start with parent issue #57 and related issue #54, then trace the execute stage, implementation.md steps, and the AgentRun or harness/controller entry point mentioned here. Compare the proposed parallelism and failure-handling options, and define the orchestration, conflict, and partial-failure behavior needed for a complete implementation.

Written by the indexing model from the issue text.