Consider std.Io async / co-scheduled swarm (zig-async-style) as follow-on to threaded runtime

## Summary

The swarm runtime (#34) uses a **dedicated OS thread** plus bounded command/event channels, with `std.Io.Threaded` providing futex-backed `Io.Mutex` / `Io.Condition` / `Io.Event` for cross-thread sync. That matches the first milestone and keeps a simple embedder boundary (`submit` / `nextEvent`).

## Enhancement

Evaluate a **deeper integration** with Zig 0.16 **`std.Io` async patterns** (tasks, `Future`, cancelation, unified timeouts)—sometimes discussed as “zig-async” in the ecosystem—so the swarm can be **co-scheduled** with transport (zquic, TCP, etc.) on a **single Io runtime** instead of (or in addition to) a dedicated thread.

Possible directions called out in #34’s discussion:

- A `Swarm.tick()` (or equivalent) that drains command and transport work from an embedder-driven Io loop.
- Optional replacement or complement to `startBackground` / `run` when the process already owns `Io` and wants fewer threads and **consistent cancelation** across operations.

## When this is worth doing

- The node (e.g. Zeam) moves toward **one primary Io loop** and wants gossip/req-resp on the same scheduler as the rest of I/O.
- Cross-cutting **cancelation** and **timeout** behavior should apply uniformly to swarm-adjacent work.

## When to keep the current model

- FFI or glue-layer parity where a **fixed worker thread** and **blocking / timeout-based event pull** stay the clearest contract.
- Minimal coupling to Io task lifetimes on the embedder side.

## Non-goals (for this issue)

- No requirement to remove the threaded API; a follow-on could offer **both** shapes behind clear docs.

## References

- #34 (swarm runtime baseline)
- `std.Io` / `Io.Threaded` in Zig 0.16