enhancement(orchestrator): burst-size rule should cover file modifications, not just creations

## Summary

The orchestrator's current Burst Dispatch Rule says (paraphrased): "When dispatching story-writer or product-owner to CREATE >8 artifacts, split into 'create' and 'integrate' sub-bursts."

This rule covers artifact CREATION but not artifact MODIFICATION. In practice, modification bursts can be just as context-heavy:

- ftc-blue pass-7 PO-B burst: modified 18 existing files (4 HO files for schema nesting, 4 BCs for various fixes, BC-INDEX, HOLDOUT-INDEX, L3-PRD, etc.) — well above any reasonable burst-size threshold.
- ftc-blue pass-8 architect burst: modified 11 files across architecture, ADRs, and subsystem shards.
- ftc-blue pass-9 PO burst: modified 12 files across BCs, holdouts, L3-PRD, error-taxonomy, and the invariants tree.

These bursts succeeded but were at the edge of context coherence. Small mistakes appeared:

- Pass-7 spec-steward burst lost architect's parallel edits during L2-INDEX rename (see Issue #1 [parallel-edit-data-loss] — partly attributable to the same wide-scope dispatch).
- Pass-8 architect's combined-bump of v1.6→v1.7→v1.8→v1.9 in a single burst created a sync hole that the adversary caught the next pass (H-2: ARCH-INDEX row stale).
- Several agents reported "linter auto-bumped versions further" — version-state ambiguity from too many concurrent file touches.

## Proposed change

Extend the Burst Dispatch Rule to cover modifications:

> When dispatching story-writer, product-owner, architect, spec-steward, or similar agents to MODIFY >12 existing files, split into focused sub-bursts of ≤8 files each. Each sub-burst should have a coherent theme (e.g., "fix save-schema nesting in HO files" — one sub-burst; "fix L3-PRD §3 FR rows" — another sub-burst).

For clarity, the rule should distinguish:

- Artifact creation: ≤8 per burst
- Artifact modification: ≤12 per burst
- Cross-file rename or namespace migration: should NOT be combined with other agents in the same burst (separate concern, separate dispatch — see also Issue #1 for the rationale).

## Applies to

- `agents/orchestrator/AGENTS.md` — Burst Dispatch Rule section
- `skills/run-phase/SKILL.md` — burst-planning guidance

## Acceptance criteria

- [ ] AGENTS.md documents the modification threshold
- [ ] Concrete examples of "good split" vs "bad single burst"
- [ ] Cross-file rename rule (no concurrent edits) explicitly documented

## Found during

ftc-blue Phase 1d adversarial cycle (2026-06-23, vsdd-factory@1.0.0-rc.21). Pass-7 PO-B burst (18 file modifications) was the trigger.

## Notes

The 18-file pass-7 burst succeeded and the PO did good work — but the failure modes that DID surface (small content cascade misses, version-bump ambiguity) all trace back to "too much surface to track in one prompt."