feat: Implement touchSet conflict prediction and blast radius scoring

[nigel-dev]

Description

The touchSet field exists in the JobSpec schema (file glob patterns indicating which files a job expects to modify), but no logic uses it. Implementing conflict prediction would warn users before launching jobs with overlapping file globs, preventing wasted compute on work that will inevitably conflict at merge time.

Use Case

When orchestrating a plan with multiple jobs, two jobs may unknowingly modify the same files. Currently, this is only discovered at merge time — after both jobs have run to completion. With touchSet conflict prediction:

1. Pre-launch validation: Before launching a plan, check for overlapping touchSets between parallel jobs (jobs without dependency ordering). Warn or block.
2. Blast radius scoring: Score each job by how many files it touches and how many overlap with other jobs, helping the user assess risk.
3. Auto-inference: After a job completes, capture git diff --name-only and store as the actual touchSet for future reference.

Proposed Solution

Phase 1: Static conflict detection

• In orchestrator.ts validatePlan() or startPlan(), compare touchSets of jobs that can run in parallel (no dependency chain between them).
• Use glob matching (e.g., Bun.glob or minimatch) to detect overlaps.
• Return warnings in the plan creation response.

Phase 2: Auto-inference

• After a job completes and before merge, run git diff --name-only on the job's branch.
• Store the result as actualTouchSet in the job state.
• Use this for future plans with similar prompts.

Phase 3: Blast radius scoring

• Score: (overlapping files with other jobs) / (total files touched).
• Surface in mc_plan_status and mc_overview.

Files Involved

• src/lib/schemas.ts:58 — touchSet field definition (already exists)
• src/lib/plan-types.ts:47 — touchSet type (already exists)
• src/lib/orchestrator.ts — validatePlan() needs conflict checking logic
• src/tools/plan.ts — surface warnings in plan creation response

Additional Context

From the master audit report (Section 9: Phase 2 roadmap): "Implement touchSet conflict prediction + blast radius scoring" and "Auto-infer touchSet from git diff --name-only." The schema infrastructure is already in place — this is purely logic implementation.

[nigel-dev]

Additional Phase: Post-Completion touchSet Enforcement (Pre-Merge Gate)

From a real-world incident where agents modified files they were explicitly told not to, causing merge conflicts that killed an autopilot plan.

The current phases in this issue focus on pre-launch prediction (comparing declared touchSets) and auto-inference (capturing actual files changed). Missing is the enforcement step between job completion and merge:

Phase 1.5: Pre-merge touchSet validation

After a job completes and before the merge train processes it:

1. Run git diff --name-only on the job's branch vs base
2. Compare actual changed files against the declared touchSet globs
3. If files outside touchSet were modified:
   • Block the merge — do not enqueue into merge train
   • Mark job as failed with a clear error: "Modified files outside touchSet: [list]. Expected only: [touchSet globs]"
   • In supervisor mode, trigger on_error checkpoint
   • In autopilot mode (with feat: Autopilot graceful degradation with job retry — pause on error instead of hard-fail #39), pause for user intervention

This catches the exact scenario where an agent ignores its file boundaries — something pre-launch prediction can't catch because it only compares declared touchSets, not actual behavior.

Where this fits

Pre-launch (Phase 1)     → "These touchSets overlap, you'll probably get conflicts"
Post-completion (Phase 1.5) → "This job touched files it wasn't supposed to — blocking merge"
Auto-inference (Phase 2)  → "Here's what the job actually touched for future reference"

Implementation location

In orchestrator.ts reconciler, between the completed → ready_to_merge transition and the merge train enqueue. Or in merge-train.ts processNext() as a pre-merge validation step.

Related: #39 (autopilot graceful degradation — determines what happens when this gate rejects a job)

[nigel-dev]

Dependency note: Phase 1.5 (pre-merge touchSet enforcement) rejects jobs that touched out-of-scope files — but rejection without recovery just kills the plan with a better error message. #39 adds the retry mechanism (mc_plan_approve(retry: "job-name")) that makes rejection recoverable: user fixes the branch, retries, merge train re-evaluates. #39 is a hard dependency for touchSet enforcement to be useful in autopilot.