refactor(plugins): give host-service resolution its own home

[rmyndharis]

Second step on plugin-loader.service.ts, after the config-defaults seeder.

Why

The loader carried five private resolvers — MessageService, SessionService,
ConversationMappingService, PluginInstanceService, SearchProviderRegistry — each a lazy require
plus a non-strict ModuleRef.get. Both halves are load-bearing and neither is about loading plugins:

• the lazy require avoids a static edge that closes
  plugin-loader → message → session → engine.factory → core/plugins barrel → plugin-loader, which
  corrupts MessageService's constructor paramtype metadata at boot;
• ModuleRef instead of constructor injection avoids the provider cycle
  PluginLoaderService → SessionService → EngineFactory → PluginLoaderService.

That reasoning was spelled out three times inside a file that otherwise has nothing to do with
module-load order.

What changes

PluginHostServices owns the pair and the explanation. The loader keeps its ModuleRef parameter and
builds the locator in the constructor body, so the constructor signature is untouched — all 33
positional constructions across six spec files, and the three spec subclasses overriding
createSandboxHost, compile and pass unchanged.

The loader also stops naming the five services: four type-only imports leave with the bodies.
MessageService stays, because dispatchConversationMedia still takes it as a parameter type.

Two tests moved

getSearchRegistry's own tests reached it through a private cast on the loader
((loader as unknown as { getSearchRegistry })) and needed twenty lines of config/storage/HookManager
scaffolding. Against PluginHostServices the same two assertions need one line. They were moved rather
than kept alive by a delegate on the loader, which would have preserved the reach-in that made them
brittle.

Suite total is unchanged at 4011 — nothing added, two tests relocated. Suite count 249 → 250 for the
new file.

On the plan this came from

The earlier plan justified a prep commit rewriting those 33 constructions to Test.createTestingModule,
on the grounds that moving fields would force a spec rewrite. Checked at source, that was not needed
here and was skipped: the constructor already absorbs new dependencies through @Optional — its own
comment records exactly that — so only reordering or removing a parameter forces the churn. The same
plan also called this step a prerequisite for breaking a plugin-loader ↔ plugin-storage require
cycle; that cycle does not exist today either.

Verification

Backend lint, prettier --check, tsc --noEmit over the full project including specs, build, 4011 unit
tests, 137 e2e tests, and the dashboard build all pass on Node 22.