fix(bus): synchronous handler registration to de-flake round-trip tests

[hartsock]

What this PR does

Hardens the #52 de-flake by fixing the root-cause nondeterminism the
direct-dial round-trip tests were papering over with a fixed sleep.

Bus::handle_requests registered its handler on a detached tokio::spawn
and returned before that task had run. A request dialed to the topic in the
gap found no handler in Inbox::dispatch_request, which silently returns
Ok(None) (no reply) — the asker just times out. On a loaded CI runner the
sleep(200ms) crutch can lose that race; that is precisely the flake class
#52 set out to eliminate.

• inbox.rs: the handlers map only ever holds its lock for a brief
  get().cloned() / insert() — never across an .await — so it does not
  need tokio::sync::RwLock. Switch it to std::sync::RwLock, make
  register_handler a synchronous fn, and add a handler_count()
  diagnostic accessor.
• bus.rs: handle_requests now installs the handler before it returns
  (no spawn, no window). Drops the 4x yield_now() crutch in the in-memory
  round-trip unit test.
• tests: remove the now-needless sleep(200ms) from the deterministic
  direct-dial round-trips (bus_roundtrip.rs, mcp_stdio.rs).

Test plan

• New regression test handle_requests_registers_synchronously_no_spawn_race
  (agent-mesh-bus/src/bus.rs): asserts the handler is registered the instant
  handle_requests returns, with no yield between. Verified it
  deterministically fails on the old spawn-based code (handler_count 0
  vs 1) and passes now.
• Stress-ran the sleep-removed tests to confirm the synchronous path is
  stable without the timing crutch:
  • request_reply_roundtrip_via_direct_dial_no_mdns — 30/30
  • mcp_server_direct_addr_round_trips_to_live_responder — 30/30
  • request_reply_roundtrip_over_in_memory_transport (yields removed) — 30/30
• just check (workspace fmt + clippy -D warnings + test) and just cov-ci
  (--fail-under-lines 75) green locally via the pre-push hook. pyo3
  feature build clippy-clean.

Out of scope

• The direct-dial CLI/MCP feature (listen pubkey banner, amesh send --addr/--pubkey, mesh_request addr+pubkey) and the initial tiering of
  the mDNS tests already landed on main via feat(cli): direct-address dial for amesh send + pubkey in listen banner (#52) #53/feat(mcp): direct-address dial for mesh_request + de-flake mcp_stdio round-trip (#52) #55/feat(mcp): mesh_publish tool — surface publish_to / publish_to_direct (#56) #57; this PR only
  hardens their determinism.
• The two bus mDNS tests and the resolve-mode CLI/MCP tests stay
  #[ignore]d — they uniquely exercise real multicast discovery.

Refs #52 — de-flake portion. The issue's feature scope appears already
complete on main; leaving the close decision to a human rather than
auto-closing.