CLAUDE.md: document leave+enter as the way to pick up SDP/codec deploys

Every live RTCPeerConnection is locked to the SDP it was created with.
Page JS reloads don't reach into existing PCs; only fresh negotiation
does. So when a deploy changes fmtp / rtcp-fb / SFU codec registration,
the user just leaves the space and re-enters — no full tab reload
needed.

Caught during the NACK+transport-cc+usedtx rollout: hard refresh wasn't
required, leave+enter was enough.

CLAUDE.md

@@ -154,3 +154,25 @@ recomputes the hashes (`web/stamp.js`).
      `~/git/www.unturf.com/zebra-report/` (`chat.html` → `index.html`;
      `zebra-audio.html`, `how-it-works.html`, `host-your-own.html` keep their
      names) → commit → **push to origin**.
+
+### Picking up a new SDP/codec deploy — `leave` then `enter`, no full reload
+
+When a deploy changes SDP munging (`preferStereoOpus`, codec fmtp params,
+RTCP feedback negotiation, or the SFU's codec registration), the page-level
+JS update is not enough on its own. Every existing `RTCPeerConnection`
+(`sfuPubPC`, `sfuSubPC`, `sfuScreenPC`, `sfuCameraPC`, every mesh peer) is
+locked to whatever was negotiated when it was created — its codec params,
+its rtcp-fb, its stereo flag, its NACK behaviour. The PC won't re-negotiate
+those on its own, and the new client code can't retroactively rewrite the
+old SDP.
+
+So after the new build is live, the user does **not** need a full tab reload:
+
+- **`leave` then `enter` the space.** That tears down every PC and rebuilds
+  them, so the next offer/answer round trip is the new client talking to
+  the new SFU with the new params. Fresh negotiation, all changes active.
+
+Full reload is only required for changes to the page shell itself (DOM
+structure, button wiring, CSS, the entry/orientation flow before joining a
+space). For everything that lives inside an existing PC, prefer
+`leave` + `enter`.