Resolve device interactors behind a composed capability #2555

Problem

src/daemon/snapshot-interactor-capture.ts reaches interactor mechanics through a dynamic
import('../core/interactors.ts') and calls getInteractor(device). That is the only production
edge leaving the daemon zone through a dynamic import, so the ranked-spine rules (R4 cycles, R5
back-edges, R6 type inversions) never see its direction, and R76's target predicate never named it
either: the file it lands on is not in the src/platform-runtime* family, even though that module
reaches the platform runtime through src/provider-device-runtime.ts.

src/core/interactors.ts also reads isActiveProviderDevice and getProviderDeviceInteractor from
src/provider-device-runtime.ts, so it is the reason #2541 cannot reach zero root edges from
src/ alone: the daemon and src/core share one ambient interactor lookup.

Desired behaviour

Interactor resolution arrives as a composed capability the daemon is handed, the way the platform
gateway, host diagnostics, and resource cleanup already are (ADR 0019 section 1/2). The daemon calls
the capability with a device; root composition names src/core/interactors.ts. The daemon zone then
holds no interactor lookup and no dynamic import of a module that reaches platform mechanics, and
src/core/interactors.ts keeps a root edge only from the composition module that owns it.

Acceptance

• The dynamic src/daemon/snapshot-interactor-capture.ts -> src/core/interactors.ts edge is gone.
• R76's inventory records no leaked-platform-mechanics edge whose target is reached dynamically.
• The interactor capability is bound at the same composition site that installs the provider-device
  admission, so one change names both.