fix(orchestrator): carry a failed batch's reason to the request error log

[behinddwalls]

Summary

Why?

When a batch failed, every request in it terminated as error with an empty message: mergesignal and speculate recorded only the terminal batch state, and conclude terminated the request with an empty reason — so a "did not land: error" carried no diagnostic at all. The reason is known at the failure site, but the requests are terminated later, in conclude.

What?

Carry the failure reason to conclude on the fan-out message's metadata rather than persisting it as batch state. mergesignal stamps the merge result's reason (or "merge failed" when it is empty) and speculate stamps "no speculation path could pass"; conclude reads it from the message and passes it to TerminateRequest, which already writes it to the request's terminal log. The landed and cancelled paths carry no reason, exactly as before.

This mirrors the dead-letter path, which already sources its reason from the delivery context. Message metadata is durably persisted and redelivered by the queue backend, so the reason survives at-least-once retries — and the batch entity stays purely structural, with no new field and no schema migration. A publish.MessageWithMetadata helper and a shared topickey.MetadataKeyFailureReason constant carry the wiring.

The demo client's run summary also surfaces the reason, so a failed request reads id=error: <reason> instead of a bare id=error.

Test Plan

✅ bazel test //submitqueue/orchestrator/... (14/14). Updated tests assert the reason rides the conclude message metadata (mergesignal, speculate finalize) and reaches the request's terminal log (conclude). Broad build and CI gates (gazelle / tidy / mocks / fmt) clean.

Stack

1. feat(demo): add BURST mode for a simultaneous enqueue of independent changes #615
2. @ fix(orchestrator): carry a failed batch's reason to the request error log #616