Expose provider preparation and pre-initialization host policy

[Brian Krabach (bkrabach)]

Strict bundle preparation currently aborts before a host can isolate an unavailable provider, and session creation does not give the host a callback before module mounting and lifecycle routing. Add two opt-in mechanisms so applications can preserve configured account identity while applying their own failure policy.

Bundle.prepare(provider_failure_policy=...) reports root/agent provider source-resolution and activation failures individually. Accepted failures remain in the mount plan and private outcomes; the resolver blocks their exact source instead of borrowing another instance's successful path or retrying silently. Repeated accounts share one source activation. Tools, hooks, orchestrators, contexts and bundle-package failures retain existing strict behavior; cancellation propagates.

PreparedBundle.create_session(before_initialize=...) and spawn(before_initialize=...) await an explicit host callback after resolver/working-directory/mention setup and before initialization. Hosts can install Core's provider failure policy for root, resume and child paths. No callback or new preparation policy is enabled by default; this does not select accounts or add routing fallback.

Validation: 120 focused preparation, activation, source cache, configuration-isolation, mention, observability and spawning tests pass. New cases cover unavailable and healthy sources sharing a module ID, exact source aliases, per-account/root/child outcomes, immutable configuration, strict non-provider/package failures, cancellation, and root/resume/child callback ordering using the installed native Core session/coordinator. New helper and tests pass Ruff; git diff --check passes. No live providers, runtime package installs, production state, or native builds were used by these tests.

This is a prerequisite for microsoft/amplifier-unified#182, alongside microsoft/amplifier-core#116. It does not complete the host or routing integration. Outcomes contain private specs/exceptions and must not be copied directly into UI state. Failed or unknown provider sources require a new preparation rather than unqualified lazy substitution; ordinary module lazy activation is unchanged.