Add an opt-in bounded mailbox (with overflow policy)

Summary

The actor mailbox is hardcoded to an unbounded channel (spawned-rt re-exports tokio unbounded_channel as channel, used by ActorRef::spawn in tasks/actor.rs). There is no way for a caller to bound it or shed load.

A per-connection / per-request actor whose handler awaits an unbounded-time operation (e.g. writing to a slow or half-dead network peer), fed by several fixed-rate, fire-and-forget producers (send_interval timers + spawn_listeners) and drained serially, will grow its mailbox without bound and never reclaim it once the handler wedges in .await. The only mitigation today is to build a separate bounded outbound queue in application code.

Proposal

An opt-in bounded mailbox with an overflow policy, e.g.:

ActorRef::spawn_with_mailbox(actor, Mailbox::Bounded { capacity, on_overflow })
// on_overflow ∈ { Block (backpressure), DropNewest, DropOldest, StopActor }

Default stays Unbounded (no behavior change). This lets a careful caller cap per-actor memory in one line, matching what Akka / Actix / Ractor offer.

Repro

A ~80-line standalone reproduction built on this framework shows the unbounded mailbox + an awaited slow sink growing live heap linearly and never freeing; with a bounded mailbox + stop-on-overflow it stays flat. Happy to share.

Notes

Companion to a separate issue on cancellation not being able to interrupt a wedged handler — together they turn a silent, unrecoverable, unbounded-memory situation into a bounded and/or recoverable one. Neither is a bug per se; both are hardening enhancements motivated by a real production memory leak in a long-running networking service using per-connection actors.

Start in tasks/actor.rs at ActorRef::spawn and trace the spawned-rt re-export of tokio's unbounded channel. Define how the proposed bounded mailbox and each overflow policy should integrate while preserving the default Unbounded behavior; done means the opt-in API and policy behavior are covered by tests.