Driver state-machine gaps in Rust runtime (strictness follow-up)

[fasterthanlime]

Context

We stabilized Swift CI with targeted runtime hardening, but during that work we compared Rust runtime behavior against a stricter phase/lifecycle model (single-owner transitions, explicit channel lifecycle states, no ambiguous delivery semantics).

This issue tracks the remaining Rust-side gaps versus that stricter model.

Gaps observed

1. Channel item delivery currently uses try_send, and item delivery can be dropped when queues are full or receiver is gone.
   • rust/vox-core/src/driver.rs around handle_channel item/close/reset forwarding.
2. Channel buffering for not-yet-registered channels is map-based and pragmatic, but not encoded as an explicit lifecycle FSM (open/closing/closed with transition guards).
   • rust/vox-core/src/driver.rs channel_buffers, register_rx_channel_impl, handle_channel.
3. Data-after-close handling relies on queue behavior and sender registry updates rather than a first-class channel state machine with explicit invalid-transition handling.
   • same areas as above.

Desired direction

• Introduce explicit channel lifecycle state tracking and transition checks.
• Make delivery semantics explicit under pressure (no silent drop unless spec-defined and observable).
• Keep resume/disconnect semantics explicit and generation-aware.

Non-goals

• No protocol-level semantic changes.
• No relaxing of schema rules.

Why now

Swift work surfaced how easy it is to hide state transition bugs behind concurrency scheduling. Rust is in a better place structurally, but tightening these areas would reduce latent race-risk and make correctness easier to reason about.