refactor: Reply to HTTP handlers without holding a tokio worker

[kimsun721]

Reply to HTTP handlers without holding a tokio worker

Why

A handler waited for a media loop's reply with a blocking recv() and sent its request with a blocking send(). Both held a tokio worker: the first for up to one lap, the second for as long as the loop's channel stayed full. ADR 0007 deferred this on the belief that tokio::sync channels need a runtime on the loop's side. They do not.

Changes

Replies

• A reply goes over tokio::sync::oneshot, and the handler awaits it.
• Stream key resolution asks every loop, so its reply uses tokio::sync::mpsc with one sender per loop. The handler takes the first room id and answers 401 once every loop has said no.

Requests

• The request channel stays a bounded std sync_channel. A handler sends with try_send and answers 503 when the channel is full. The channel also carries media from the mux, and media cannot wait while a request can be retried.
• Stream key resolution answers 503, not 401, if any loop is full, since the key may belong to that loop.
• stream_requests_refused counts refusals, with a panel on the Grafana dashboard. They are not logged, since they come in floods.

Docs

• ADR 0012 records the decision and supersedes ADR 0007.
• The worker limit leaves the README and the architecture overview.

Tested

• cargo test: unit tests in room.rs updated for the new reply types; the integration suites pass unchanged.
• A full channel is not covered by a test, since filling it needs a stalled loop.

Closes #82