[vinayagg]

When direct HTTPS cannot reach another Bees Client, try a reliable WebRTC data channel using werift before falling back to the existing encrypted relay. Desktop and hosted Clients use the same transport. Setup descriptions travel through the existing authenticated relay; the resulting direct channel carries the existing certificate-pinned TLS exchange and per-thread access checks.

The integration bounds signaling and data buffers, limits setup to 15 seconds, drains writes before closing SCTP, cleans up connections on shutdown, and obtains a fresh relay grant after a failed or unsupported WebRTC attempt. STUN URLs are configurable with BEES_WEBRTC_STUN_URLS. No server API change is required.

Validation completed in the isolated worktrees:

• Desktop npm run check passed.
• Five transport tests passed, covering a 5 MiB binary transfer, bounded buffering, invalid signaling/frames, deadlines and cancellation.
• The real Server suite passed all 225 tests with the paired integration changes, including a 1 MB file over WebRTC, unchanged access restrictions and old-client relay fallback.
• The actual hosted Client proof passed using local fixtures (80 model calls and 183 gateway requests).

This branch starts at 410ef40. Current main's subsequent d37b6af imports thread-applications.js without committing that file. Merge-result CI may therefore fail until that separate upstream issue is resolved; this PR does not include unrelated application work.

Real cross-network NAT traversal and platform installer verification remain untested. No release or deployment has been performed.

Related PRs: https://github.com/Bees-bot/bees-server/pull/75 (integration tests; merge after Desktop) and https://github.com/Bees-bot/bees-website/pull/74 (publish with the Client release).