bug(orchestrator): silent data loss when parallel agents edit and rename the same file

## Summary

When the orchestrator dispatches multiple agents in parallel and one of them renames or moves a file that another is concurrently editing, the rename's copy+delete sequence silently discards the parallel edit. No error, no warning, no merge conflict — the edits simply don't survive.

This is a serious data-integrity defect: a fix that the agent reported as complete is in fact lost, and the regression is only caught in a later adversarial pass (typically 1–3 passes later when the missing content surfaces as a finding).

## Reproduction

Phase 1d pass-7 (ftc-blue, cycle-001, 2026-06-23):

1. Orchestrator dispatched architect + spec-steward + PO + ux-designer + state-manager in parallel.
2. Architect's task included adding `DI-009` and `DI-010` rows to `domain-spec/index.md §5`.
3. Spec-steward's task (H-8) was to rename `domain-spec/index.md` → `domain-spec/L2-INDEX.md` (file already had `id: L2-INDEX` in frontmatter; the filename was the dangling reference).
4. Spec-steward executed copy+delete; architect's DI-009/010 additions to the original file were not preserved into the renamed file.
5. Both agents reported their tasks complete. Pass-8 adversary (H-1) caught the missing DI-009/010 rows in L2-INDEX as a HIGH finding.

The regression was a pass-7 fix landing intact in a now-deleted file. State-manager did not detect any anomaly because both agents committed to the same orphan branch and the diff was internally self-consistent.

## Proposed change

The orchestrator must detect when parallel dispatches will touch the same file (whether by edit, rename, or move) and serialize them, or at minimum issue a pre-burst warning.

Concretely:

- Before dispatching a parallel burst, parse each agent's intent (from the prompt's `Files to modify` section or from agent-declared targets if such metadata exists).
- Compute file-set overlap. If any two agents target the same file, OR if one agent renames a file that another agent's prompt names, the orchestrator should either (a) sequence the dispatches, or (b) merge the two prompts into a single agent, or (c) hard-fail with a clear diagnostic.

Lighter-weight alternative if intent extraction is brittle:

- Hook into agent completion. After each agent in a parallel burst completes, snapshot the file tree. If a file rename + same-file edit pattern is detected post-hoc (file X deleted; file Y created; X's pre-burst content + Y's post-burst content has lossy diff), emit a HIGH-SEVERITY warning to the orchestrator and force a verification re-read.

## Applies to

- `agents/orchestrator/` — burst dispatch logic
- Possibly `hooks-registry.toml` resolvers — could add a pre-dispatch file-overlap resolver
- Policy: orchestrator AGENTS.md "Burst Dispatch Rule" needs a sub-rule covering this

## Acceptance criteria

- [ ] Orchestrator detects file-rename + concurrent file-edit collisions before they happen, OR
- [ ] Orchestrator detects them post-hoc and surfaces a clear regression warning
- [ ] Documented test case demonstrates the detection (synthetic burst with intentional collision)
- [ ] AGENTS.md or orchestrator skill prompt documents the rule

## Found during

Phase 1d adversarial cycle on `ftc-blue` (2026-06-23, vsdd-factory@1.0.0-rc.21). Specifically pass-7 H-7 fix loss, surfaced as pass-8 H-1. Cost: 1 full remediation pass to recover.

## Notes

This is the kind of defect that's invisible during a successful burst and only surfaces N passes later as "regression" — making root-cause investigation expensive. Worth elevating to HIGH severity.