feat(runway): wire merge controller to Merger extension (#283)

## Summary
- Wire the merge controller to the `merger.Factory` extension so it
performs the committing merge instead of just logging
- Publish `MergeResult` (with produced revisions) to the `merge-signal`
topic — `SUCCEEDED` on clean merge, `FAILED` on `merger.ErrConflict`
- Mirrors the merge-conflict-check controller pattern from #280
- Publish errors are retryable; deserialize/factory/merge errors are
non-retryable
- Update example server wiring with merger factory, registry, and
merge-signal topic

Stacked on #280 — merge that first.

## Test plan
- [x] Unit tests: success (with output verification), merge conflict,
merger infra error, factory error, publish error (retryable),
deserialize error
- [x] `bazel test //runway/controller/merge:merge_test` passes
- [x] `bazel build //example/runway/server:runway` builds cleanly
- [x] `make gazelle && make fmt` — in sync

🤖 Generated with [Claude Code](https://claude.com/claude-code)

refactor: rename example/ to service/

The example/ tree holds the runnable server/client wiring for every
domain — it is the composition root, not throwaway demo code. Rename it
to service/ to reflect that role and update all references: Bazel labels,
Go importpaths, Makefile compose vars and targets, docker-compose build
contexts, integration/e2e suite paths, and documentation.

Also refresh the docs for the current layout:
- Rewrite service/README.md to include the runway service and the
  stovepipe Ingest/process pipeline (previously documented as Ping-only).
- Add service/runway/README.md and service/stovepipe/README.md.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

feat(runway): wire merge controller to Merger extension (#283)

## Summary
- Wire the merge controller to the `merger.Factory` extension so it
performs the committing merge instead of just logging
- Publish `MergeResult` (with produced revisions) to the `merge-signal`
topic — `SUCCEEDED` on clean merge, `FAILED` on `merger.ErrConflict`
- Mirrors the merge-conflict-check controller pattern from #280
- Publish errors are retryable; deserialize/factory/merge errors are
non-retryable
- Update example server wiring with merger factory, registry, and
merge-signal topic

Stacked on #280 — merge that first.

## Test plan
- [x] Unit tests: success (with output verification), merge conflict,
merger infra error, factory error, publish error (retryable),
deserialize error
- [x] `bazel test //runway/controller/merge:merge_test` passes
- [x] `bazel build //example/runway/server:runway` builds cleanly
- [x] `make gazelle && make fmt` — in sync

🤖 Generated with [Claude Code](https://claude.com/claude-code)

feat(runway): wire merge-conflict-check controller to Merger extension (

#280)

## Summary
- Wire the merge-conflict-check controller to the `merger.Factory`
extension so it performs the actual dry-run merge check instead of just
logging
- Publish `MergeResult` to the `merge-conflict-check-signal` topic —
`SUCCEEDED` on clean merge, `FAILED` on `merger.ErrConflict` (ack, not a
controller error)
- Publish errors are retryable (`errs.NewRetryableError`);
deserialize/factory/check errors are non-retryable (DLQ)
- Update example server wiring with noop merger factory and signal topic
in the registry

## Test plan
- [x] Unit tests: success, merge conflict, merger infra error, factory
error, publish error, deserialize error
- [x] `bazel test
//runway/controller/mergeconflictcheck:mergeconflictcheck_test` passes
- [x] `bazel build //example/runway/server:runway` builds cleanly
- [x] `make gazelle` — BUILD files in sync
- [x] `make fmt` — no formatting changes

🤖 Generated with [Claude Code](https://claude.com/claude-code)

(fix)build: disable proto rule generation, rely on checked-in .pb.go …

…for go-code compatibility (#293)

<!-- Provide a summary in the Title above. Example: "Feature: add user
authentication" -->

## Why?
We want the smoothest DX for consuming the OSS submitqueue repo in
go-code. Today go-code's `go_repository` uses `build_file_generation =
"on"`, so its Gazelle regenerates BUILD files for the vendored repo.
This causes conflicts and mismatches, and every version bump risks new
patching.

The root issue is that OSS carries proto types twice: as checked-in
`.pb.go` in `protopb/`, and as Bazel-generated code via
`go_proto_library` in `proto/`. Removing the Bazel proto rules in favor
of the checked-in `.pb.go` fixes several things at once:

- Eliminates duplicate proto definitions. The two generation paths share
the same importpath, which caused the duplicate-importpath ambiguity and
forced the `gazelle:resolve` workarounds. Collapsing to a single source
removes that whole class of conflict.
- Serves non-Bazel consumers. The Bazel-generated code only exists
inside a Bazel build graph. Anyone consuming submitqueue via plain `go
build/go get` (including OSS users) can only use the checked-in .pb.go,
so that path must work regardless. The Bazel proto rules are a redundant
second path that serves no one the checked-in files don't already serve.

## What?
Disable Gazelle proto rule generation and remove all proto compilation
rules, relying solely on checked-in `.pb.go` files.

- Add `# gazelle:proto disable_global` to prevent Gazelle from
regenerating proto rules on future make gazelle runs
- Remove the `gazelle:resolve directives` that are no longer needed
- Remove `proto_library`, `go_proto_library`, and alias `go_library`
rules
- Keep `exports_files` for `make proto` codegen
(`tool/proto/BUILD.bazel`)

## Test Plan
- `make build` - pass
- `make test` - 65/65 unit tests pass (integration/e2e tests fail due to
Docker dependency, pre-existing)
- `bazel build //tool/proto:generated` - proto codegen still works
- `make gazelle` - zero warnings, no duplicate-importpath ambiguity
- Validated in go-code with `--override_repository` pointing at this
branch: all 71 targets build, all 20 tests pass across stovepipe,
submitqueue/gateway, and submitqueue/orchestrator

## Issue
<!-- 
Link the issue here. 
- Use 'Closes #123' if this is the final fix. 
- Use 'Part of #123' or just '#123' if the feature is still in progress.
-->

---------

Co-authored-by: chenghan.ying <chenghan.ying@uber.com>

docs: specify conventional commits in CLAUDE.md (#289)

## Summary
Add a Commit Style section requiring the Conventional Commits
specification for commit messages.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

## Test Plan
✅ make fmt && make build && make test && make check-mocks && make
e2e-test

## Issues


## Stack
1. #287
1. #288
1. @ #289

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs: add AGENTS.md symlink to CLAUDE.md (#288)

## Summary
Symlink AGENTS.md -> CLAUDE.md so agent CLIs that read AGENTS.md (e.g.
Codex CLI) get the same repository guidance, with CLAUDE.md as the
single
source of truth.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

## Test Plan
✅ make fmt && make build && make test && make check-mocks && make
e2e-test

## Issues


## Stack
1. #287
1. @ #288
1. #289

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

feat(orchestrator): emit batched request log from batch controller (#287

)

## Summary
Previously the batch controller was not publishing a request log on
completion. This is inconsistent with the other controllers, which
publish a terminal request log when its action is complete.

This PR emits a request log after the batch is persisted and before
publishing to score.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

## Test Plan
✅ make fmt && make build && make test && make check-mocks && make
e2e-test

## Issues


## Stack
1. @ #287
1. #288
1. #289

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Split active batch states by controller use (#285)

## Summary
Split active batch state helpers
    
Use separate active-state sets for cancellation and batch creation. Add
the scoring request status so batches in scoring do not leave requests
with stale log state.

## Test Plan
✅ make fmt && make build && make test && make check-mocks && make
e2e-test

## Issues


## Stack
1. #284
1. @ #285
1. #287
1. #288
1. #289

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Regenerate stale consumer controller mock (#284)

## Summary
`make check-mocks` was failing.

This PR ran `make mocks` to fix the mocks so `make check-mocks` is
passing.

## Test Plan
✅ `make fmt && make build && make test && make check-mocks && make
e2e-test`

## Issues


## Stack
1. @ #284
1. #285
1. #287
1. #288
1. #289