feat(stovepipe): Announce validation start events (#652)

## Summary
**What**:
- Announce that validation of a commit has begun as soon as the pipeline
admits it, alongside the existing announcements for validation outcomes.
- Repeat that announcement when an already-admitted request is
redelivered, reusing the original event identity so consumers can
discard the duplicate.

**Why**:
- Let downstream systems track a validation from start to finish,
instead of only learning it happened once a verdict exists.
- Keep the announcement from being lost when the pipeline fails after
durably admitting the request.

## Test Plan
- [x] Add unit tests.

## Revert Plan
- Revert this PR. Nothing consumes the start event yet, so publishing
just stops with no downstream impact.

## Issues
-
[CODEM-466](https://linear.app/uber/issue/CODEM-466/emit-events-when-we-start-a-new-validation-range)

feat(stovepipe): Announce validation results (#646)

## Summary
**What**:
- Publish an event whenever a commit's validation result becomes
durable, carrying whether the commit is healthy or broken and what it
was measured against.
- Publish a distinct event when validation ends without a verdict, and
fail the work when either event cannot be sent.

**Why**:
- Let subscriber systems act on trunk validation results as they land,
instead of polling for them.
- Keep the event vendor-neutral so each deployment wires its own
subscriber to forward results onward, instead of building any single
environment's delivery path into the pipeline.

## Test Plan
- [x] Add unit tests.

## Revert Plan
- Revert this PR. The events are additive and nothing consumes them yet.

## Issues
-
[CODEM-459](https://linear.app/uber/issue/CODEM-459/record-step-emit-events-internally-on-new-green)

fix(messagequeue): clarify canceled worker polls (#647)

## Summary
Intent:
- Distinguish expected partition-worker teardown from actionable polling
failures.

Changes:
- Log canceled in-flight polls at info only when the worker context is
also canceled.
- Keep active-worker cancellations and other storage failures at error
level.

feat(errs): classify YARPC status errors (#641)

## Summary
Intent:
- Retry transient YARPC failures instead of dead-lettering them as
unknown errors.
- Preserve dependency attribution while distinguishing caller
cancellation.

Changes:
- Classify typed YARPC statuses by retryability and origin.
- Register the classifier with Stovepipe and document the mapping.

build(api): expose RPC proto sources (#639)

## Summary
Intent:
- Allow downstream Bazel repositories to vendor published RPC contracts
directly. This will let us use a rule in our internal repo to keep the
vendored copies up to date on each sync.

Changes:
- Make the Runway, Stovepipe, SubmitQueue gateway, and SubmitQueue
orchestrator service proto sources publicly visible.

refactor(speculation): move the scorer in with the rest of speculation (

#625)

## Summary
### Why?

The Speculator is composed from a generator, an allocator and a scorer,
but only two of the three lived under
`submitqueue/extension/speculation/`. The scorer sat at the top level as
if it were a peer of storage or the change provider, which it is not:
there is no scoring stage, and nothing outside the speculation generator
has ever asked it for a price. The tree implied a seam that does not
exist.

### What?

`submitqueue/extension/scorer/` becomes
`submitqueue/extension/speculation/scorer/`, taking its contract,
`heuristic`, `composite`, `fake` and `mock` with it. Import paths and
BUILD files follow; no code changes.

The `mocks` Makefile target listed the old path explicitly. It is
dropped rather than repointed, because the
`./submitqueue/extension/speculation/...` pattern already on that line
now covers it.

## Test Plan
✅ `bazel test //submitqueue/... //service/...` — 53 tests pass
✅ `make gazelle` — BUILD files regenerated
✅ `make mocks` — unchanged output from the new path

## Issues

feat(stovepipe): Consume hook events (#632)

## Summary
**What**:
- Register the hook stage and its dead-letter stage in Stovepipe's
consumer wiring, on a topic named for the domain, with a resolver that
hands every event to the no-op hook.

**Why**:
- Wire the stage in a second domain, so attaching a real integration to
Stovepipe is a resolver swap rather than new plumbing, and two domains
on one queue backend keep their own hook topics.

## Test Plan
- [x] Add unit tests.

## Revert Plan
- Revert this PR. Nothing publishes hook events yet and the resolver
returns only a no-op hook.

## Issues
-
[CODEM-416](https://linear.app/uber/issue/CODEM-416/hooks-integration-downstream-notificaiton)

## Stack
1. #607
1. #608
1. @ #632

feat(orch): Consume hook events (#608)

## Summary
**What**:
- Register the orchestrator's hook stage, so lifecycle events are
consumed from the queue and handed to the integrations each event
resolves to. No integration is wired yet, so events are accepted and
discarded.
- Register the matching dead-letter stage, so an event that fails every
retry is recorded and alerted on instead of accumulating unread.

**Why**:
- Prove the delivery path end to end before anything produces an event,
so a later change adds producers to a route that already works.
- Keep a deployment with no integrations configured distinguishable from
one that is silently losing events.

## Test Plan
- [x] Add unit tests.

## Revert Plan
- Revert this PR. Since nothing publishes hook events yet and the
resolver returns only a no-op hook, no side effect is lost.

## Issues
-
[CODEM-416](https://linear.app/uber/issue/CODEM-416/hooks-integration-downstream-notificaiton)

## Stack
1. #607
1. @ #608
1. #632

feat(hook): Deliver events to integrations (#607)

## Summary
**What**:
- Consume lifecycle events from a durable queue and hand each one to the
integrations it resolves to, running them concurrently and retrying then
dead-lettering the ones that keep failing.
- Record every dead-lettered event with its full payload and failure
reason, and count it on a metric meant to page.

**Why**:
- Keep a slow or broken integration from stalling or failing the work
that triggered it.
- Make a lost notification recoverable and impossible to miss, since
nothing else in the system notices when one goes missing.

## Test Plan
- [x] Add unit tests.

## Revert Plan
- Revert this PR. No service constructs the controller or subscribes to
the hook topic.

## Issues
-
[CODEM-416](https://linear.app/uber/issue/CODEM-416/hooks-integration-downstream-notificaiton)

docs: align READMEs and RFCs with current code and AGENTS.md conventi…

…ons (#629)

Updates the documentation to match the actual repository layout and
code:

- Replaces all stale CLAUDE.md references with AGENTS.md, the
authoritative conventions file.
- Fixes the project-layout description in README.md and
submitqueue/README.md: shared code lives under platform/, not the
now-removed top-level entity/extension/core/ directories.
- Expands the empty submitqueue/orchestrator/README.md with the pipeline
stages it runs.
- Updates Stovepipe READMEs to reflect Ping + Ingest RPCs and the full
ingest → process → build → buildsignal → record pipeline, plus DLQ
reconcilers.
- Corrects fully-qualified gRPC service names in service/README.md and
TESTING.md to use the uber.* proto packages.
- Corrects Runway topic names in doc/rfc/runway/workflow.md to match the
actual TopicKey constants (merge-conflict-check, runway-merge,
merge-conflict-check-signal, merge-signal).
- Clarifies integration-test Makefile targets in TESTING.md and removes
the non-existent integration-test-{service} placeholder.
- Fixes the stale TODO line-number reference in modular-queue-wiring.md.