… log (uber#616)

## 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. uber#615
1. @ uber#616