fix(orchestrator): stop dependency-analysis DLQ failing requests a live batch owns

[behinddwalls]

Summary

Why?

The batch stage mints a batch per delivery, so a lost ack leaves two batches for one request, and dependency analysis is where one of them is chosen. Its DLQ reused the generic batch reconciler, which fails every member request. A dead-lettered duplicate therefore wrote Error over a request whose chosen batch was still live; that batch went on to land the change while the request stayed reported as failed. The same reconciler would also fail a batch that speculate had already admitted, racing land.

What?

• Add NewDLQDependencyAnalysisController, which decides by the batch's state:
  • Creating with a request already carried by another batch past Creating: a duplicate, left inert (same test the primary controller uses to abandon it).
  • Creating otherwise, Created, or Failed: the batch owns its requests and nothing downstream will advance it, so it is failed and fanned out as before.
  • Any later state: a downstream stage owns it; acked untouched.
• Wire it as the dependency-analysis stage's DLQ and update the DLQ README's controller mapping (which also still listed speculate under the generic controller).

Test Plan

✅ bazel test //submitqueue/orchestrator/... (new table-driven DLQ test covers every batch state, duplicate vs owner, and lookup failure)
✅ make lint-fmt, make check-gazelle
TestConflictAnalyzerFailure_ReconcilesFromDLQ (e2e) exercises the owner path and should still see the batch Failed and the request Error.

Stack

1. fix(orchestrator): repair Created record when dependency-analysis re-announces #875
2. @ fix(orchestrator): stop dependency-analysis DLQ failing requests a live batch owns #876

🤖 Generated with Claude Code