planner: wave/batch scheduler has no file-collision check — same-epic stories touching the same file get parallelized, guaranteeing merge conflicts

## Summary

The wave/batch planner treats stories as parallelizable when they have no BC-level dependency, but performs no FILE-level collision check. Two stories in the same epic that both modify the same implementation file get scheduled into the same parallel batch on separate worktrees branched from the same base — guaranteeing that exactly one PR merges cleanly and every subsequent sibling PR conflicts.

## Evidence from ftc-blue W3B2 (E-005 puzzle chain)

- STORY-5.05.002 and STORY-5.05.005 both modify `scripts/systems/puzzle_system.gd`
- Both scheduled in Wave 3 Batch 2, parallel worktrees, same base `8b894a0`
- Divergence at merge time (`git diff --stat` vs merge-base):
- main side (5.05.002, merged first via PR #69): **+153/−30**
- branch side (5.05.005, PR #70): **+102/−13**
- Result: PR #70 `mergeable: CONFLICTING / DIRTY` the moment PR #69 landed
- STORY-5.05.003 (same epic, same file, same stale base) is queued to hit the identical conflict next — the collision is serial across the whole epic

The factory even pre-registered the symptom as a drift item (F-P10-STORY-5.05.005-L02 "cross-story sibling-lag — deferred to PR merge") during adversarial convergence, then proceeded into the guaranteed conflict anyway.

This is NOT routine git noise: the conflict was deterministic at scheduling time from static information (story file-lists / epic subsystem mapping).

## Requested fix

1. **Batch planner file-collision check:** before finalizing a parallel batch, intersect the predicted file-touch sets of candidate stories (from story `files:` frontmatter, subsystem mapping, or the stub-architect's file list). Stories with overlapping write-sets MUST be serialized (or explicitly stacked), never parallelized.
2. **Epic-affinity heuristic:** stories in the same epic targeting the same subsystem default to sequential scheduling unless the planner proves disjoint file sets.
3. **Stacked-PR option:** where product pressure demands parallelism, schedule colliding stories as a stacked chain (story B branches from story A's head, PR B bases on branch A), so integration happens continuously instead of at merge time.
4. **Wave-schedule template:** add a "file-collision matrix" section so the human gate can see predicted overlaps before approving the batch.

## Cost incurred

- One full pr-manager conflict-resolution dispatch (hand-weaving two independently-converged versions of a 457-line system file)
- Convergence-certificate invalidation for the losing story (see companion issue)
- The same cost will repeat for every remaining story in the epic that was branched from the stale base

## Cross-refs

- Companion issue: post-merge convergence-certificate invalidation (filed separately)
- L-W3B2-10 (worktree branch-point staleness proportional to branch age) — adjacent, already codified in ftc-blue lessons.md
- F-P10-STORY-5.05.005-L02 drift item (ftc-blue STATE.md)