Rethink the `flashdreams.serving` API

[jatentaki]

Currently the code in flashdreams.serving is components shared between OmniDreams and LingbotWorld webRTC servers but some of it probably doesn't belong in core flashdreams - e.g. I would argue that keyboard input processing belongs in javascript flashend in the first place, not even in python.

P0 We should probably mark these interfaces as internal/experimental before public release
P1 rethink which are the truly reusable components (e.g. thread orchestration, HW accelerated webRTC encode) to expose stably

[jarcherNV]

This is still valid. In fact, after the shared WebRTC extraction in #357, more of the reusable serving surface now lives under flashdreams.serving.webrtc, so we should be explicit about its stability.

I think the next step is for us to take over the P0 part: add clear docs/module wording that flashdreams.serving and especially flashdreams.serving.webrtc are experimental integration-facing utilities, not a stable public API yet.

The larger P1 design question can stay open after that: decide which pieces should become stable long-term APIs, such as WebRTC app bootstrap, media encoding/track handling, session orchestration, and whether keyboard/input resampling belongs in Python at all.