[zoedsoupe]

Problem

Three gaps in the realtime client:

• A channel whose join fails while the socket stays up stays :errored until the next socket reconnect. Phoenix retries a failed join on its own with backoff; the client did not.
• Adding an identical postgres_changes binding is silently accepted, but the server collapses identical filters into one subscription, which desyncs the client's positional binding ids.
• While investigating that, we found the ids were already misaligned with two or more distinct bindings: the join payload was emitted newest-first while the reply handling reverse-zipped as if it were oldest-first, so each stored binding could be assigned another binding's id.

Solution

• Add Supabase.Realtime.Rejoin, a pure module holding the phoenix backoff sequence (1s, 2s, 5s, then 10s), and a per-channel rejoin timer owned by the Registry. A failed join (error/timeout reply, phx_error, failed leave) arms a retry that re-joins with a fresh join_ref and token. The timer is cleared on :open/:closed, on a successful join, on unsubscribe and on close. A :rejoin_after_ms start option overrides the sequence.
• Reject a duplicate postgres_changes binding at the on/3 boundary with {:error, :duplicate_binding}, comparing event, schema, table, filter and select.
• Emit the join payload's postgres_changes entries oldest-first, matching realtime-js, so the server's positional ids line up with the stored bindings.
• Fix the Realtime.send/3 docs, which showed broadcasting through the raw send path.

Rationale

The timer lives in the Registry because every join and cancel trigger already lands there; putting it in the Connection would need new cross-process messages. Dedup returns a tuple rather than silently ignoring the duplicate (as realtime-js does) to match the boundary contract already set by :invalid_select. The payload-order fix makes the existing reverse-zip correct without touching it, and matches the reference client.