bug(orchestrator+harness): single Agent-tool dispatch fans out to N parallel agent IDs (5x consistency-validator) — upstream cause of #273-class staging-area races for writing agents

## Summary

In one switchboard-blue session a single orchestrator-side dispatch of `vsdd-factory:consistency-validator` surfaced **five running agent IDs in parallel** with the same prompt:

```
ad15530f, abd4c026, a0fa1eec, af2d3b67, aadeda12
```

I (the orchestrator) only invoked the Agent tool once for this dispatch. The harness/runtime/dispatcher created the duplicates — the agent IDs are independent. I refused to spawn further consistency-validators and used the first-returning instance's output. The other four ran to completion against the same `.factory/` view and produced near-duplicate reports.

## Why this matters

1. **Token waste** — five parallel runs of a read-only audit agent against the same artifact set is ~5× the cost of one run, for zero coverage gain.
2. **#273 amplifier** — `consistency-validator` is read-only so it didn't fire #273's staging-area race. But if this same dispatch-duplication behavior fires for a *writing* agent (PO, architect, story-writer, state-manager), it deterministically reproduces #273 every time. The duplicate-dispatch bug is the upstream cause; #273 is the visible symptom when writers are duplicated.
3. **Diverged verdicts** — when multiple fresh-context instances disagree on the same input, downstream consumers (the orchestrator, the user) have no way to pick the "right" verdict. Five copies of consistency-validator could theoretically produce five different reports if any of them hits a non-deterministic path. This is the same calibration-drift class as #278, but driven by accidental dispatch fan-out rather than legitimate cross-context audit.

## What I observed

- One Agent-tool invocation for `subagent_type=vsdd-factory:consistency-validator`.
- Five returning agent task IDs.
- Five independent task completions with overlapping-but-not-identical output.
- The orchestrator (me) treated this as a known harness anomaly, refused to spawn more, used the first result.

## Hypothesis (mechanism)

The most plausible mechanism, without internal harness logs, is **dispatch retry without idempotency check** — the harness or transport retried the spawn request after a timeout/lost-ack, but the original spawn had already succeeded; the retry created a second instance instead of recovering the original task handle. Five retries would imply four timeouts plus the original; or a fan-out misconfiguration.

Alternative: a `parallel()` / fan-out call somewhere in the dispatch path with an unintended array length of 5.

## Reproduction

- Switchboard-blue session, Phase 3 Wave 5, S-6.02 review cluster.
- Plugin `vsdd-factory 1.0.0-rc.21`, Claude Code.
- Observed once in this session for `consistency-validator`. Unclear if it has fired for writing agents in earlier waves — would manifest as "burst commits don't match what I dispatched" and route to #273 for triage.

## Suggested mitigation

1. **Dispatch ID dedup at the harness layer** — every Agent-tool invocation gets a client-side request UUID; harness deduplicates by UUID on receive, returns the existing task handle on retry instead of spawning a new one.
2. **Orchestrator-side defensive check** — `agents_list` before every dispatch, refuse to spawn if an agent of the same `subagent_type` with substantially-equal prompt is already running. (Cheap; doesn't fix the underlying race; protects against operator-error retries too.)
3. **Telemetry**: emit a structured log line for every Agent spawn that includes `{request_uuid, agent_id, subagent_type, prompt_hash}` so post-hoc analysis can detect 1-request → N-spawn fan-out.

## Related

- drbothen/vsdd-factory#273 — staging-area race; downstream amplifier of this duplicate-spawn defect for writing agents
- drbothen/vsdd-factory#278 — calibration drift across fresh-context instances; this defect can simulate the drift artificially via accidental fan-out

## Labels

`bug` (only).