refactor(daemon): absorb androidAdbExecutor DI slot into the generic provider scope

[thymikee]

What changed

src/daemon/request-handler-chain.ts threaded a platform-concrete
androidAdbExecutor?: AndroidAdbExecutor parameter through the generic
RequestHandlerChainParams. That value was already produced by the daemon's
existing generic per-request provider-injection mechanism —
RequestPlatformProviderScope, built by withRequestPlatformProviderScope in
request-platform-providers.ts — but request-router.ts flattened it out
(androidAdbExecutor: providerScope.androidAdbExecutor) into a separately
named chain-level slot before calling runRequestHandlerChain.

This PR:

• Replaces RequestHandlerChainParams.androidAdbExecutor with
  providerScope: RequestPlatformProviderScope.
• Updates the session route (runSessionHandler, the sole in-chain consumer)
  to read params.providerScope.androidAdbExecutor when building
  handleSessionCommands' own params — which is otherwise unchanged.
• Updates request-router.ts to pass the whole resolved providerScope
  through instead of extracting androidAdbExecutor out of it first.

The generic chain signature no longer names any platform.

Why this is behavior-neutral

• The exact same RequestPlatformProviderScope object — and its
  androidAdbExecutor field, resolved the same way by
  withRequestPlatformProviderScope — now reaches the session handler; only
  the path it travels through RequestHandlerChainParams changed, not its
  value or how it's resolved.
• Everything downstream of handleSessionCommands (session.ts,
  session-doctor.ts, session-doctor-android.ts, session-native-perf.ts,
  session-observability.ts) is untouched.
• Full provider-integration coverage that exercises the real ADB executor
  end-to-end through the daemon route (android-lifecycle.test.ts's "Android
  Settings flow uses scripted ADB provider", doctor.test.ts,
  android-recording.test.ts, etc.) passes unchanged.

I did not find a case where this DI slot could not be absorbed without
changing production behavior — the value flowing through
RequestHandlerChainParams was always exactly providerScope.androidAdbExecutor,
so this stayed pure wiring.

Validation

• New wiring-equivalence test (request-handler-chain-provider-scope.test.ts):
  mocks handleSessionCommands and proves (a) the exact androidAdbExecutor
  function reference passed into providerScope reaches it unchanged for a
  session-routed request, and (b) an empty provider scope still forwards
  undefined (as before).
• pnpm exec tsc -p tsconfig.json — clean
• pnpm check:layering — 136/136 structural tests pass
• pnpm check:affected --run — 80 test files / 337 tests passed (including
  the full provider-integration suite: android-lifecycle, doctor,
  android-recording, record-trace-android-liveness, etc.), plus format,
  lint, layering, and build/declarations checks

Part of #1739 (wave 0).

[github-actions]

Size Report

Metric	Base	Current	Diff
JS raw	2.18 MB	2.18 MB	-10 B
JS gzip	712.0 kB	712.0 kB	-3 B
npm tarball	838.3 kB	838.3 kB	-5 B
npm unpacked	2.92 MB	2.92 MB	-10 B

Startup median (7 runs, lower is better):

Scenario	Base	Current	Diff
CLI --version	29.0 ms	29.8 ms	+0.8 ms
CLI --help	69.5 ms	69.8 ms	+0.3 ms

Top changed chunks:

Chunk	Raw diff	Gzip diff
dist/src/internal/daemon.js	-10 B	-3 B

[thymikee]

Reviewed exact head bb9569f5. This is code-review clean. RequestPlatformProviderScope stays confined to the request-router/composition and route-adapter seam; runSessionHandler immediately projects the precise androidAdbExecutor into the unchanged session-handler API, so handlers do not receive a service-locator bag. The production resolution path and exact executor reference are preserved, ADR 0003 route ownership remains unchanged, and this matches ADR 0019 / #1739 wave-0 wiring cleanup. The regression is non-vacuous: 2/2 pass at head, and replacing the projection with undefined fails the exact-reference case. Existing provider-integration coverage exercises the full router-to-ADB path. No source issue remains; code-ready, with only the affected decision-kernel mutants check currently pending.

[github-actions]

PR Preview Action v1.8.1
Preview removed because the pull request was closed.
2026-08-11 15:34 UTC