The request log had two persistence paths: the gateway wrote some entries
directly, while the orchestrator ran the `log`-topic consumer that wrote all
downstream entries to storage. Having the orchestrator persist the request log
blurs ownership — the orchestrator is a pipeline that should only emit events,
not own the request-log table. Concentrating all writes in the gateway gives a
single owner for the request log and keeps the orchestrator free of request-log
storage writes.

The request-log persistence consumer moves from the orchestrator to the gateway:

- Move `submitqueue/orchestrator/controller/log/` → `submitqueue/gateway/controller/log/`
  (importpath, doc comment, and default consumer group `orchestrator-log` →
  `gateway-log`). Logic is unchanged.
- Orchestrator: `TopicKeyLog` becomes publish-only (subscription dropped), the
  log controller registration and import are removed, controller count 11 → 10.
  It still publishes via `submitqueue/core/request.PublishLog`.
- Gateway: builds a consumer (generic + mysql classifiers), registers the moved
  log controller on `TopicKeyLog` with a subscription (group `gateway-log`),
  starts it, and drains it with `Stop(30000)` on shutdown — preserving the
  128+SIGTERM graceful-exit contract.
- Add `HOSTNAME=gateway-dev` to both gateway compose files for a stable
  subscriber name; update the workflow RFC and gateway README.
- Tests: add a gateway integration test that publishes to the log topic (as the
  orchestrator does) and asserts the gateway consumer persists it, and an e2e
  test that lands a request and asserts Status advances to `started` —
  exercising the publish→consume→persist path across both services.

The gateway keeps its two synchronous direct writes (`accepted` on Land,
`cancelling` on Cancel) for read-your-write visibility at RPC return. Both are
gateway writes, so the invariant holds: only the gateway persists the request
log; the orchestrator only publishes. This works because gateway and
orchestrator already share the same queue and app databases.

- ✅ `bazel build` of both servers + the moved package
- ✅ `make test` — unit tests pass (incl. the moved log_test)
- ✅ `make check-gazelle`, `make check-tidy`, `make lint` (fmt + license)
- ✅ `make integration-test-submitqueue-gateway` — new `TestRequestLogConsumer`
  verifies the gateway consumer persists a log entry published to the log topic
- ✅ `make e2e-test` — new `TestLandRequest_PersistsStartedLogViaGatewayConsumer`
  verifies an orchestrator-published `started` log is persisted by the gateway
  and readable via Status; both services still exit 128+SIGTERM on shutdown

- Make the log-consumer subscriber name unique per instance (hostname+PID)
  so co-located gateway processes don't contend for the same partition lease.
- Report the gRPC server error first in the shutdown errors.Join (it is the
  primary failure; consumer-stop is secondary cleanup).
- Clarify in the README that the gateway is the sole owner (writer and reader)
  of the request log; Status/Cancel read directly, orchestrator only publishes.
- Extract named poll constants (persistTimeout/persistPollInterval) in the
  gateway integration and e2e suites with a comment explaining that the
  in-container consumer is observed black-box via Status, so a bounded poll is
  used in lieu of an in-process channel/HookSignal wait.

Follow-ups split out: design doc (#211) and DLQ PublishLog() (#212).

Co-Authored-By: Oz <oz-agent@warp.dev>