feat(ws): opt-in includeRepeats streams later hearings over new paths

[MrAlders0n]

A flood packet reaches an observer more than once: first from the nearest repeater, then again whenever a repeater further out rebroadcasts it, each time over a different path. We only store and stream the first hearing per (packet, observer), because the observation insert is ON CONFLICT DO NOTHING and the event is only built when the row went in. That's the right behaviour for storage, but a live map that animates a packet spreading through the mesh never sees most of the spread.

This adds a connection-wide opt-in, configure { includeRepeats: true }. Clients that send it also get those later hearings as ordinary packetObservation events with packet.isRepeat: true. Clients that don't opt in see byte-identical events.

How it works:

• Nothing is stored for a repeat. It's built from values handlePacket already has in hand for duplicates, and it skips GetPacketObservationCount, so observationCount is 0 on repeats.
• Exact copies are skipped. Most duplicates are the same hearing arriving via another broker, or the same path twice. The hub keeps a small shared set of (packet, observer, path) it sent in the last 2 minutes, capped at 200k hashed keys, and only new paths go out.
• Repeats can't cost first hearings. They go through BroadcastRepeat, which drops the repeat once the broadcast channel is half full. Those drops are counted and logged at most once a minute.
• Nearly free when nobody opts in. A duplicate costs one atomic load, with no JSON encoding and no query.

The protocol change is backwards compatible. An older server ignores the unknown includeRepeats field, and the new field is omitempty.

Tests cover hub routing and the opt-in counter, the drop-first path, the sent-path store (window, new path, size bound), handlePacket end to end (first hearing, broker copy, new path, same path again, opt-in off, no count query on repeats), and a real configure round trip through the handler. No API or swagger changes.