Add per-peer bandwidth attribution to egress server

[myleshorton]

Summary

• Adds a peer ID to the WebSocket subprotocol header so the egress server knows which widget peer is behind each connection
• Replaces the global ingress byte counter with per-peer atomic counters (sync.Map keyed by peer ID)
• Reports per-peer bandwidth via a new ingress-bytes-by-peer OTel metric with a peer_id attribute, preserving the existing ingress-bytes total metric
• Adds PeerID field to EgressOptions (auto-generated UUID by default), so all callers get a peer identity without code changes
• Backwards compatible: old clients without a peer ID fall back to using the consumer session ID

This is the first step toward bandwidth-based compensation for unbounded peers (see getlantern/lantern-token).

Test plan

• Deploy to staging egress server and verify ingress-bytes total metric still reports correctly
• Verify ingress-bytes-by-peer metric appears with peer_id labels in OTel collector
• Connect multiple consumers through the same widget peer and confirm bytes aggregate under one peer ID
• Connect an old client (without peer ID in subprotocol) and confirm it falls back to CSID-based tracking without errors

🤖 Generated with Claude Code

[myleshorton]

@noahlevenson and @garmr-ulfr this is just background work that's necessary if we ever did want to integrate a crypto token.

[noahlevenson]

When do you need to land this? My only thought: we have an open ticket to decouple the Lantern-specific parts of Unbounded and refactor them to our own proprietary layer, because when they're tightly coupled, it makes it harder for people to integrate Unbounded into their own projects. The stuff in this PR seems like a prime candidate for the "Lantern proprietary" Unbounded package...