fix(realtime): tie channel join_ref to the actual join push ref

[grdsdev]

Follow-up to #1626 for the v3 branch (different realtime implementation, same class of bug, different root cause).

RealtimeChannel.subscribe() sent the phx_join message with join_ref hardcoded to None, then set self.join_ref to a brand-new, unrelated ref generated after the join succeeded. Every later push on the channel (leave, broadcast, presence track/untrack) carried a join_ref that never matched any ref the server had actually seen for that channel — defeating its purpose of letting the server detect stale messages after a rejoin. Newer Phoenix versions rely on this and silently drop pushes that don't line up.

Fix: generate the join ref once in subscribe(), use it as both ref and join_ref on the phx_join message, and store that same value as channel.join_ref for subsequent pushes.

Test plan

• Added tests/test_join_ref.py: a local in-process websocket server (same pattern as test_reconnection.py's RealtimeServer) records every client-sent message and asserts join/broadcast/track/untrack/leave all carry a join_ref equal to the actual phx_join ref. All 4 fail on unmodified v3 (confirmed) and pass after the fix.
• ruff check / ruff format --check: clean.
• mypy src/realtime tests: clean.
• pytest tests/: the new tests plus the rest of the fast suite pass. test_connection.py/test_presence.py need a local Supabase stack and test_reconnection.py has a pre-existing port-reuse flake (address already in use on ::1:55555) — both reproduce identically on unmodified v3, unrelated to this change.

Fixes SDK-1526