Scale out error ingestion for EF (1/3): ingestion owns its dispatcher

[johnsimons]

Part 1 of 3 introducing scale-out of error ingestion for EF persistence, where several
processes drain the error queue into one shared database.

This part contains no scale-out feature. It is groundwork plus a bug fix, and stands on
its own.

Ingestion takes its dispatcher as an argument

ErrorIngestor and AuditIngestor held a Lazy<IMessageDispatcher>. That is a
constructor dependency which cannot be satisfied at construction time: the dispatcher is
registered by AddNServiceBusEndpoint behind a factory that dereferences the transport
seam, so resolving it before the endpoint's hosted service starts throws a bare
NullReferenceException. The Lazy wrapper, and the comment apologising for registration
order next to it, were the tell.

It is not a constructor dependency, it is a call-time collaborator. The ingestors do not
own a transport: they take message contexts, persist them, announce them and forward them.
The dispatcher belongs to whoever received the batch.

So Ingest and VerifyCanReachForwardingAddress now take an IMessageDispatcher, and
ErrorIngestion / AuditIngestion pass the one from the TransportInfrastructure they
already create. ImportFailedErrors and ImportFailedAudits take the Lazy that the
ingestors used to hold, so their behaviour is unchanged.

Three things fall out: Forward passing anyContext.TransportTransaction now visibly
belongs with the dispatcher it is handed to rather than one from a different
infrastructure, the start-order hazard leaves the ingestion path, and the ingestors become
testable with a fake dispatcher and no container.

AuditPersister threads the dispatcher through as well. It is hand constructed inside
AuditIngestor's constructor, so leaving it holding a Lazy would have the file arguing
with itself. Its IMessageSession is untouched: saga audit commands genuinely need the
endpoint.

Shutdown ordering, which was duplicating forwarded messages

StopAsync tore the transport infrastructure down before draining the channel. Worse,
EnsureStopped stops the receiver with new CancellationToken(canceled: true) ("stop
receivers ASAP"), which fires the registration in OnMessage that cancels every in-flight
TaskCompletionSource. Those messages were abandoned and redelivered on the next start,
after the drain had already forwarded them. With ForwardErrorMessages on, every
graceful shutdown with a non-empty channel put duplicates in the error log queue.

The order is now: stop receiving under the shutdown token, complete the writer, drain, then
tear down. Stopping under the real token means StopReceive waits for in-flight messages
while the loop is still running and the infrastructure is still up, so they ingest, forward
once, and their receives actually commit.

This is what the (previously dead) finally block in StopAsync was always shaped for.
Watchdog is untouched; the split is local to each ingestion class.