Infrastructure: Qualify native-core TurboModule support with a real consumer #4380

Goal

Exercise the module half of native-core's FRNNativeCoreSpec boundary with a representative real feature. Part of #4275. This remains deferred until a genuine consumer justifies it; do not create a speculative module merely to share view behavior.

Observed baseline — 2026-10-15

Callout and FocusZone exercise the component path. Package codegen uses type: all and Windows has both component/module generators, but this is not evidence that a real TurboModule works in supported consuming hosts.

Acceptance

• Identify the concrete non-view feature/consumer and review its public platform contract and lifecycle.
• Add the correctly named Native<Name>.ts schema, thin native module adapters, explicit exports, and a genuine shared service only when reuse exists. Components and modules are peer service consumers; view commands must not route through a global module.
• Verify Apple/Windows codegen/provider registration, packed source ownership, errors/cancellation, dispatcher affinity, and cleanup in real consuming hosts and declared renderer/version combinations.
• Preserve Office bridging-header and CocoaPods-module build compatibility, legacy Win32 ownership, and existing component registrations.
• Record actual native invocation/results and unsupported hosts. A generated interface, compilation, or JS mock does not establish module readiness.

Evidence

Retired handoff: b55d6c9a3:packages/agentic/native-core/plans/modernization.md; durable packaging/admission rules in packages/agentic/native-core/README.md and AGENTS.md. Candidate wave-three 5f6e7af1252bcfe087dcd1672afaa4ceb7c5efbb is selective reference material, not qualified module delivery.