`session.create` deadlocks when a `SessionFsProvider` is bound

Start in rust/src/session.rs at start_prepared_create, call_with_inline_callback, and spawn_event_loop, then compare the ordering with session.resume. Reproduce the hang using a bound SessionFsProvider and a scripted CLI that sends sessionFs.stat during create; done means create completes within a bounded timeout and the regression test fails on the current implementation.

Repo/version: github/copilot-sdk, tag rust/v1.0.14 (e60d9037); CLI runtime cli-1.0.84-5.

Behaviour: With a SessionFsProvider bound on the client, session.create never returns. The CLI issues sessionFs.* requests during create; nothing on the client side answers them yet, so the RPC waits forever (RpcSessionFs carries no request timeout).

Cause: start_prepared_create (rust/src/session.rs:1167) sends the session.create RPC (call_with_inline_callback, :1394) before it spawns the event loop (spawn_event_loop, :1419) that dispatches inbound sessionFs.* requests. session.resume spawns its event loop before its RPC (:1636) and does not hang.

Fix shape: Spawn the event loop for the non-cloud create arm before the RPC, as resume does. The inline stash grows from (SessionId, SessionRegistration) to (SessionId, Option<SessionChannels>, RegistrationToken) so the early loop takes the channels while the cancel-safety guard keeps the token. The existing guard cancels shutdown on every early return and the loop exits on shutdown.cancelled(), so no extra abort plumbing is needed.

Regression test: bind a provider, drive create against a scripted CLI that issues sessionFs.stat during create, assert create completes within a bounded timeout. Must time out on current code.

Downstream: a consumer of this crate carries a local patch for this and cannot drop it until it is fixed upstream.