rfc(submitqueue): add modular queue wiring (#290)

## Summary

RFC at `doc/rfc/submitqueue/modular-queue-wiring.md` proposing a
declare-don't-assemble engine for the orchestrator's per-queue extension
wiring, topic registry, and controller lifecycle:

1. **`platform/lifecycle`** — `Component` interface (`Start`/`Stop`) and
ordered `Group` with rollback-on-partial-failure
2. **`platform/pipeline`** — `Construct[D]` engine that unifies topic
registry, controller creation, DLQ pairing, and consumer lifecycle into
one typed call over a `[]Stage[D]` table
3. **Service self-declaration** — each service exports a `Deps` struct
(seams), a `Stages` slice (topology), and a `Controllers` struct; no
assembly code
4. **Host-private profiles** — per-queue extension selection stays in
the host's `profiles.go`, never crosses the library boundary
5. **Fluent builder** — `submitqueue.New().WithQueue(...).Create()`
wraps the engine for the common single-orchestrator case

Recommends profiles stay in Go code (Option C) rather than adding hints
to `QueueConfig`. Also adds the RFC to `doc/rfc/index.md`.

Doc-only change, no code modifications.

## Test Plan
CI/Build validation

## Revert Plan
git revert

## API Changes
No API changes

## Monitoring and Alerts
Standard monitoring via existing dashboards

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

Author: JamyDev

doc/rfc/index.md

@@ -16,6 +16,8 @@ Design documents and technical proposals, grouped by scope. Shared/cross-cutting
 - [Build Runner](submitqueue/build-runner.md) - Vendor-agnostic BuildRunner interface, provider-neutral BuildStatus lifecycle, and how the orchestrator wires it into the build stage
 - [Extension Contract](submitqueue/extension-contract.md) - When extensions take orchestrator identity (request/batch) and resolve granular content themselves vs. take controller-resolved data; revises the BuildRunner base/head contract
 - [Gateway Status and List APIs](submitqueue/status-list-api.md) - Gateway-owned request context, materialized current status, sqid or change-URI status lookup, and queue admission listing
+- [Speculation](submitqueue/speculation.md) - Why SubmitQueue speculates, the path/tree model, and the two pluggable seams: speculation-tree enumeration and path selection
+- [Modular Queue Wiring](submitqueue/modular-queue-wiring.md) - Declare-don't-assemble engine (`pipeline.Construct`) that unifies topic registry, controller registration, DLQ pairing, and lifecycle ordering into one typed call; services self-declare via Deps struct + Stages slice, hosts own per-queue profiles and transport
 
 ## Stovepipe