mediad: a websocket for programs, next to the datachannel for people

[Nixxx19]

architecture.md §5.3 says an agent shouldn't have to go through webrtc — it doesn't want a 30fps h264 track to decode, it wants a frame every second or two and a state blob. and remote-webrtc.md §12 has the websocket surface on the deferred list as "a few dozen lines once §5's routing exists".

§5's routing exists now, so here it is. it's at /agent on the port the console is already served from.

turned out to be smaller than i expected because session::run already takes a pair of String channels and doesn't know what carries them. so the whole transport is pumping text frames into one and out of the other, and everything else is the code that was already there.

the part i think matters: it's the same api, not a second one. a line arriving on the socket goes through session::run against the same route table the datachannel uses, so what an agent can call is what a console peer can call, decided in one place. you can't add a method to one transport and not the other.

one thing that fell out: route::refusal said "not available over WebRTC", which is now wrong for half the callers. it says "over this transport" instead.

test opens a real websocket against the real router, checks hello comes back, checks a permitted call reaches robotd and a refused one is refused.

cargo test --workspace, clippy with -D warnings and fmt are green on linux. mediad is linux-only so a mac skips it.