Consolidate discovery module ownership and split JSONRPC orchestration responsibilities #538

Tracking plan: #528
Priority: P3. Evidence: source-confirmed maintainability and duplicate-compilation concern; no runtime speedup is assumed.

Problem

The JSONRPC orchestration module combines handlers, configuration publication/rollback, refresh coordination, locator state transfer, and telemetry follow-up. The binary also declares find/locators modules that are already public modules in the library, creating parallel module instances instead of using one implementation boundary.

Sources: binary module declarations, library modules, JSONRPC orchestration.

Scope

Use the library discovery/locator implementation from both CLI and server entry points. Extract configuration publication and refresh coordination into independently testable components, leaving RPC handlers as thin adapters. Keep locator crates and priority ordering; avoid a workspace-wide crate merger or async rewrite.

Separate behavior changes from code movement so reviewers can verify this is behavior-preserving. Update architecture/state documentation to the final ownership model, including actual transient-versus-persistent cache lifetimes and all current locators such as Hatch. Move tests with their responsibilities without losing coverage or weakening assertions.

Acceptance criteria

• Binary and library no longer compile separate find/locators module instances; public interfaces remain deliberate and minimal.
• Configuration publication, refresh coordination, and handler adaptation have distinct, directly testable responsibilities.
• Existing CLI/JSONRPC output, error behavior, locator order, coalescing, generation checks, and state-sync semantics remain unchanged.
• Full default-feature tests, relevant feature/platform jobs, formatting, and warnings-as-errors lint pass.
• Gate client-observed refresh latency and define accurate first-environment timing #531/Benchmark long-lived PET sessions, real concurrent resolves, and inventory scaling #533 performance and Collect server subprocess coverage and report production-focused coverage gaps #534 production coverage do not regress; no unmeasured runtime-speedup claim is used to justify the refactor.
• Documentation reflects the implementation and the change does not introduce generic abstractions used only once.

Dependencies

Perform after #536, bounded scheduling #539, and output ownership #540 stabilize; the complete landing order is in #528. Use #534 coverage and #531/#533 measurements as guardrails. Smaller purely mechanical library-module reuse can be split out earlier if isolated and separately reviewed.