topic: let dora topic subscribe to zenoh directly, with the coordinator relay as fallback #4025

Follow-up to phil-opp's review on #3636. Large topic payloads shouldn't go through the coordinator at all when the CLI can reach zenoh directly. I'd like to work on this, and I'm proposing to split it into small PRs.

Today every node output is already published on zenoh (zenoh_output_publish_topic: dora/default/<dataflow>/output/<node>/<output>). Small outputs send their Arrow schema once, on the @schema sub-key. The daemon's debug subscriber rebuilds full samples from that, with a history-enabled subscriber and a schema cache (binaries/daemon/src/debug_topic.rs, dataflow_lifecycle.rs). dora topic then gets those samples relayed through the coordinator.

Proposed PRs

1. Move the debug-topic reassembly (DebugSchemaCache, retain_debug_schema, prime_debug_schema, rebuild_debug_topic_stream, prepare_debug_topic_frame) out of dora-daemon into a shared crate, so the CLI can reuse it. No behaviour change.
2. Coordinator: when a CLI subscribes, also return the zenoh endpoints of the daemons running the requested outputs (zenoh_endpoints_for), as an optional reply field that older CLIs ignore.
3. CLI: connect to those endpoints with a short timeout. If it reaches all of them, subscribe directly and rebuild samples with the shared code; otherwise use the existing relay. On a single machine this is always the direct path.
4. Docs: the direct path is the default, and when the relay is used instead. A direct zenoh subscriber doesn't go through the WS auth token or enable_debug_inspection. That isn't a new exposure (anyone on the zenoh network can already subscribe), but it should be written down.

Open questions

• Where should the shared code live: dora-core, or a small new crate?
• Should a CLI in another network namespace (e.g. a separate container) get an explicit endpoint override, or just fall back to the relay?
• dora run has no coordinator to hand out endpoints. Should it use the local daemon's endpoint directly?

The relay hardening from the same review (separate debug connections, its own runtime, a global credit budget) would come after this, as its own issue.