Extract dependency assembly out of main.go into a Service concept

[behinddwalls]

Background

In #193 (per-queue extension wiring), the example orchestrator's main.go
(example/submitqueue/orchestrator/server/main.go)
grew to construct the full set of configured dependencies inline — queue
registry, the six per-extension factory adapters, consumers, etc. Review
feedback (thread):

I think we should start moving dependencies building out of main.go - it
becomes overbloated and hard to read. Probably even introduce another
high-level concept of a "service" - an entity holding the combined set of
configured dependencies. main.go to remain as a runner of the service.

Proposal

Introduce a higher-level service concept that owns the assembled,
configured set of dependencies, and reduce main.go to a thin runner.

• Extract dependency construction (queue registry, per-extension factory
  adapters, stores, consumers, …) out of main.go into a dedicated
  service-assembly type/package.
• main.go responsibilities shrink to: parse flags/config, build the
  service, start it, handle shutdown.
• Keep the wiring-layer ownership boundary intact — per-queue routing and
  factory adapters still live in the wiring layer (see the Extensions
  guidance in CLAUDE.md), just organized behind the service rather than
  spelled out in main.go.

Scope / open questions

• Where the service type lives (example/submitqueue/... vs. promoting a
  reusable assembly into submitqueue/core/). feat(example): per-queue extension wiring; retire buildrunner/noop #193 already left a TODO to
  evaluate promoting the registry into submitqueue/core later.
• Whether this applies symmetrically to the gateway server and the
  stovepipe servers.

Follow-up to #193 (raised by @sbalabanov).