feat(queue): complete Gateway → Orchestrator queue integration

## Summary

Wire up the first stage of the queue pipeline: Gateway publishes land requests
to the queue, Orchestrator consumes and processes them. Queue infrastructure is
optional to maintain backward compatibility with existing integration tests.

## Why?

The orchestrator needs to process requests asynchronously through a multi-stage
queue pipeline. This establishes the foundation with reusable consumer infrastructure
that scales to 10+ queues.

## What?

**Consumer Infrastructure:**
- Add Consumer interface (Register/Start/Stop) for orchestrating multiple controllers
- Add Controller interface for queue message processing with per-subscription config
- Implement subscription lifecycle, automatic ack/nack, metrics, graceful shutdown
- Configurable shutdown timeout (timeoutMs parameter)

**Gateway:**
- Modify Land controller to publish requests to land_request queue after storage
- Add publisher metrics and error handling
- Queue infrastructure optional (controlled by QUEUE_MYSQL_DSN env var)
- Land API returns error if queue not configured

**Orchestrator:**
- Add Request controller to consume from land_request queue
- Wire up consumer with graceful shutdown in main.go
- Queue infrastructure optional (controlled by QUEUE_MYSQL_DSN env var)
- Server starts without queue for Ping API testing

**Entities:**
- Add Request JSON serialization (ToBytes/FromBytes)

**CLAUDE.md:**
- Extend time guideline to use int64 milliseconds for timestamps AND durations
- Add code style guidelines: use SugaredLogger, use interfaces for contracts

**Integration Tests:**
- All 3 service integration tests pass without MySQL
- Servers start successfully when queue infrastructure not configured
- Backward compatible with existing Ping API tests

## Test Plan

- 607 lines of consumer tests with channel-based synchronization
- Request entity serialization tests
- Gateway publisher integration tests
- Request controller tests with various states
- All unit tests pass
- All integration tests pass (gateway, orchestrator, speculator)

Author: behinddwalls

CLAUDE.md

@@ -70,7 +70,10 @@ entity/
 **Entity guidelines:**
 1. Keep entities pure and framework-agnostic — no external dependencies
 2. Use value types, not references
-3. Prefer `int64` Unix epoch milliseconds over `time.Time`
+3. Prefer `int64` milliseconds over `time.Time` and `time.Duration`:
+   - Timestamps: Unix epoch milliseconds (e.g., `CreatedAt int64`) — use `time.UnixMilli()` method
+   - Durations/timeouts: milliseconds (e.g., `TimeoutMs int64`, `DelayMs int64`)
+   - Use `time.Duration(ms) * time.Millisecond` to convert to `time.Duration` when needed
 4. Every field must have a comment explaining its meaning
 5. Reference other entities by ID (string or int), not directly
 6. Use string enums with clear names; assign sentinel values (`""` for strings, `0` for ints) to unreachable/unknown enum variants
@@ -204,3 +207,20 @@ make clean-proto              # Remove generated proto files
 1. **Avoid asserting on error messages** — assert on error type if it is part of the contract, or assert generic error otherwise.
 2. **Avoid blocking operations for synchronization** — do not use `time.Sleep`. Design the tested routine to signal back (channels, callbacks, condition variables).
 3. **Use testify assertions** — use `stretchr/assert` or `require` instead of `t.Fatal()`.
+
+### Code Style Guidelines
+
+1. **Use SugaredLogger for structured logging** — always use `zap.SugaredLogger` with structured logging methods:
+   - `logger.Debugw(msg, key1, val1, key2, val2, ...)` for debug logs
+   - `logger.Infow(msg, key1, val1, key2, val2, ...)` for info logs
+   - `logger.Errorw(msg, key1, val1, key2, val2, ...)` for error logs
+   - Never use unstructured methods like `Debug()`, `Info()`, `Error()`, or `Printf()`
+   - Example: `logger.Infow("starting consumer", "subscriber_name", subscriberName, "controller_count", len(controllers))`
+
+2. **Use interfaces for contracts** — define interfaces for public APIs and dependencies:
+   - Public components should return/accept interfaces, not concrete structs
+   - Unexported structs implement the interfaces
+   - Makes testing easier through mocking
+   - Example: `func New(...) Consumer` returns interface, not `*consumer`
+   - Implementation struct is unexported: `type consumer struct { ... }`
+

consumer/BUILD.bazel

@@ -0,0 +1,30 @@
+load("@rules_go//go:def.bzl", "go_library", "go_test")
+
+go_library(
+    name = "consumer",
+    srcs = [
+        "consumer.go",
+        "controller.go",
+    ],
+    importpath = "github.com/uber/submitqueue/consumer",
+    visibility = ["//visibility:public"],
+    deps = [
+        "//extension/queue",
+        "@com_github_uber_go_tally_v4//:tally",
+        "@org_uber_go_zap//:zap",
+    ],
+)
+
+go_test(
+    name = "consumer_test",
+    srcs = ["consumer_test.go"],
+    embed = [":consumer"],
+    deps = [
+        "//entity/queue",
+        "//extension/queue",
+        "@com_github_stretchr_testify//assert",
+        "@com_github_stretchr_testify//require",
+        "@com_github_uber_go_tally_v4//:tally",
+        "@org_uber_go_zap//zaptest",
+    ],
+)