[bahdotsh]

Stacked on #634. This branch contains #634's three commits. Review only the last commit, 59ae4095. Merge #634 first, then merge main into this branch.

What this does

A page cannot scan for Bluetooth, browse DNS-SD or join Wi-Fi Direct, so two browsers on one network had no way to notice each other. NearbyRoom meets the browsers behind one public address in a Nostr room derived from that address and the application id. It lists them by the label each application chose and links over WebRTC to the one a person picks. The relays carry only the setup, and the link runs on the local network.

• The room key is public by construction. Anyone can derive it from an address. It seals only presences, which hold a key used for this room and the application's label.
• Every connection code is sealed to one presence key. It uses NIP-44, under the room key as a second layer, with the role bound in. A holder of the room key reads no code and no local address.
• The application admits. admit({ peer, label }) is required and decides every offer. A refused session is ignored while its offer stays fresh, so republished offers do not ask again.
• The relays and STUN servers are the application's. A room without them refuses to open. The network address comes from the first server-reflexive candidate the application's STUN server produces.
• IPv6 rooms are per /64, because each IPv6 device has its own public address.

Documented as W13 in docs/bridges/web.md, residual risk R30, and ADR 0034. ADR 0034 records that same-network discovery for browsers needs the internet and is shared with everyone behind the address.

Supporting changes

• The transport crate gains seal_to_key and open_from_key over its existing NIP-44 code, with a round-trip and wrong-key test.
• RoomChannel in nostr-signal.js now takes its subscription and opener as a source. The nearby room reuses the signaller's relay handling, with redial, probe and keep-alive unchanged.
• test/stun-server.mjs is a STUN Binding responder in Node's standard library. It reports a fixed documentation address, so a page on one machine gets a server-reflexive candidate. test-browser.sh starts it. Firefox runs with media.peerconnection.ice.loopback on so it gathers toward loopback, the same kind of test-host setting as the existing obfuscation pref.
• The lobby example gains a nearby section. It has empty relay and STUN fields, and an inline Allow or Deny for every request.

Testing

• cargo test -p offline-protocol-web -p offline-protocol-transport --lib: 58 and 315 pass. Seven new nearby tests check:
  • Devices behind one address share a room.
  • A different address or application id gives a different room.
  • IPv6 rooms follow the /64.
  • An offer opens only for its key: an eavesdropper holding the room key reads nothing.
  • Events outside their freshness window are refused.
  • Labels are bounded.
  • Signalling rooms and nearby rooms do not read each other.
• bash bindings/web/scripts/test-browser.sh: 21 of 21 pass, seven pages in Chromium, Firefox and WebKit. On nearby.html:
  • The STUN step learns the fixed address.
  • Three nodes see each other's labels.
  • An admitted device links and a message crosses.
  • A device the host refuses gets no answer, after the host was asked.
  • A room behind another address sees nobody.
• The lobby's nearby flow, driven headlessly in two Chromium contexts against the local relay and STUN server: list, Connect, Allow, then "1 device connected" on both pages.
• Clippy is clean on the host and for wasm32, and docs build under -D warnings.

Not done

• No run on two physical devices. It is step 8 of docs/bridges/web-devices.md, which also covers the phone-on-cellular case where the two must stop listing each other.
• Devices that leave by different routes land in different rooms. A VPN, or one device reporting IPv4 and the other IPv6, has that effect. Nothing detects it, and ADR 0034 states it as a consequence.
• Nearby is browser to browser only. Native bindings have no WebRTC carrier.