## Summary
### Why?

Extension input granularity is inconsistent across the orchestrator
pipeline: `conflict.Analyzer` takes orchestrator identity
(`entity.Batch`), while `scorer` / `mergechecker` / `changeprovider` /
`buildrunner` / `pusher` take controller-resolved `entity.Change`. The
split caps what an extension can do — a real `target_overlap` conflict
analyzer and a diff-aware heuristic scorer both cannot be written today,
because the data they need is neither in the contract nor resolvable by
the extension.

### What?

Adds `doc/rfc/submitqueue/extension-contract.md` proposing that
decision/action extensions accept thin reference entities at their
pipeline-stage granularity (`entity.Request` for request-stage,
`entity.Batch` / `[]entity.Batch` for batch-stage) and resolve granular
content themselves via narrowly-injected `Factory` dependencies, while
`storage` / `changestore` / `queueconfig` stay key/value resolution
targets. `conflict.Analyzer` is the baseline. The RFC revises the
BuildRunner base/head contract (`build-runner.md`) to pass batches
rather than change lists.

Also encodes the rule in `CLAUDE.md` so new extensions and signature
changes follow it, and links the RFC from the RFC index. Documentation
only — no code changes.

## Test Plan


## Issues


## Stack
1. @ #214
1. #216
1. #217
1. #218
1. #219
1. #221
1. #222
1. #223
1. #227

## Summary
Add submitqueue/core/changeset, the single place the orchestrator
resolves batch identity into the changes a batch contains —
consolidating the batch -> requests -> changes walk that the build,
merge, and score controllers each performed privately.

Resolver exposes two single-batch fidelities, both keyed per batch so
callers with several batches loop and keep the per-batch boundary:
ChangesForBatch returns raw changes (URIs only, no change-store read)
for the build and merge stages, and DetailedForBatch returns one
ChangeInfo per claimed URI with provider details read from the change
store, for the score stage and detail-aware analyzers.

Ships with a store-backed implementation (depending only on the request
and change stores), a programmable in-memory fake, a generated mock, and
tests. The package is added unused; extensions adopt it in later
branches. entity.BatchChanges is repurposed as DetailedForBatch's output
(doc comment only). The mocks make-target gains the new package.

## Test Plan


## Issues


## Stack
1. #214
1. @ #216
1. #217
1. #218
1. #219
1. #221
1. #222
1. #223
1. #227

…lly (#217)

## Summary
Change MergeChecker.Check to take the orchestrator's request identity
(entity.Request) instead of a controller-pre-resolved entity.Change, per
the extension contract. The GitHub implementation and the fake read
request.Change themselves; the validate controller hands over the
request it already loaded.

Output is unchanged (mergechecker.Result). The factory and Config are
unchanged — no dependency injection is needed since the checker resolves
nothing beyond the change already on the request.

## Test Plan


## Issues


## Stack
1. @ #217
1. #218
1. #219
1. #221
1. #222
1. #223
1. #227

…nally (#218)

## Summary
Change ChangeProvider.Get to take the orchestrator's request identity
(entity.Request) instead of a controller-pre-resolved entity.Change, per
the extension contract. The GitHub implementation and the fake read
request.Change themselves; the validate controller hands over the
request it already loaded.

Output is unchanged: one entity.ChangeInfo per URI, each
self-identifying by URI. The provider is the external resolver, so it
needs no injected dependency — the factory and Config are unchanged.

## Test Plan


## Issues


## Stack
1. #217
1. @ #218
1. #219
1. #221
1. #222
1. #223
1. #227