Unify DI on MS.DI: migrate remaining Lamar consumers

Background

Today (2026-04-28) requests 1883432 and 1883433 wedged at status Requesting on DOrc DV 03 because two parallel DI registries got out of sync:

• Dorc.PersistentData/PersistentDataRegistry.cs — Lamar ServiceRegistry, had the new IDaemonObservationPersistentSource registration added during the daemons-modernisation work.
• Dorc.Monitor/Registry/PersistentSourcesRegistry.cs — pure MS.DI IServiceCollection, missed the same registration.

The Monitor is the only project on pure MS.DI. Every deploy (GitHub or otherwise) routed through IPendingRequestProcessor → ... → DaemonsPersistentSource threw InvalidOperationException: Unable to resolve service for type 'IDaemonObservationPersistentSource' while attempting to activate 'DaemonsPersistentSource', and a separate state-machine bug left the rows in Requesting rather than flipping them to Errored. Both immediate bugs are fixed in commit 42e6f354 on feat/649-daemons-modernisation (will land via PR #584). This issue tracks the structural fix.

Scope

Migrate every remaining Lamar consumer to Microsoft.Extensions.DependencyInjection, then remove the Lamar / LamarCodeGeneration / Lamar.Microsoft.DependencyInjection packages.

Projects still on Lamar

• Dorc.Api — Program.cs:307 builder.Host.UseLamar(...), Services/ApiRegistry.cs : ServiceRegistry
• Dorc.Core — Lamar/CoreRegistry.cs
• Dorc.PersistentData — PersistentDataRegistry.cs (the one that was in sync above)
• Dorc.OpenSearchData — OpenSearchDataRegistry.cs
• Dorc.Runner — AppRegistry.cs
• Tools.DeployCopyEnvBuildCLI, Tools.PostRestoreEndurCLI, Tools.PropertyValueCreationCLI, Tools.RequestCLI

Dorc.Monitor is already on MS.DI and stays as the reference pattern.

Acceptance criteria

• All projects above use Microsoft.Extensions.DependencyInjection exclusively.
• Lamar, LamarCodeGeneration, and Lamar.Microsoft.DependencyInjection package references removed from every .csproj.
• Persistent-source registration centralised in one place that every host (API, Monitor, Tools) calls — no two registries holding the same registrations.
• Existing test suites pass; ideally add a startup smoke test per host that validates the DI graph (Dorc.Monitor.IntegrationTests already does something similar).

Risks / migration notes

• Lamar quietly auto-wires Func<T> for any registered concrete; MS.DI does not. Audit all Func<T> and Lazy<T> constructor params; explicit Func<> registrations may be needed (PR #584 added one of these in ApiRegistry for GitHubDeployableBuild — flagged in the same PR).
• Lamar IServiceContext-factory patterns (For<X>().Use(ctx => ...)) need rewriting to IServiceProvider-factory (services.AddTransient<X>(sp => ...)).
• Lamar Scoped() / Singleton() / Transient() map cleanly to AddScoped / AddSingleton / AddTransient but the default lifetime differs (Lamar: Transient, MS.DI registration must be explicit) — every existing registration needs a deliberate lifetime.
• Lamar supports decorator chaining inline; MS.DI doesn't have native decorator support — Scrutor or hand-rolled decorators may be needed in places.

Why this is high priority

A DI registration miss like this morning's silently wedges deploys without erroring fast — the request just sits in Requesting forever and only manual cancel + monitor restart clears it. With one registry in one place, the whole class of bug goes away.

Start with Dorc.Monitor as the MS.DI reference pattern, then inspect Program.cs, the listed registry files, CLI projects, and their .csproj package references. Audit the Lamar registrations, constructor dependencies, lifetimes, factories, and decorators before running the existing suites and Dorc.Monitor.IntegrationTests. Done means all listed hosts use MS.DI, shared persistent-source registration is centralized, Lamar packages are removed, and the DI graphs validate at startup.