streaming: reset reconnect backoff after an established connection master
The backoff reset was conditioned on rotating to a different host, which a single-host consumer can never satisfy: effective_index is always 0, so the delay doubled 1-2-4-...-60s and stayed pinned at the ceiling for the life of the process no matter how healthy each connection had been. Observed against a relay closing every ~113s: every reconnect paid the full 60s, leaving the tail down 33% of the time. Measured live with forced disconnects, gaps held at ~1.38s across seven reconnects versus 1.4/2.4/4.4/8.4/16.4/32.6s without the reset. Keyed on the handshake, as jcalabro/atmos does in streaming/client.go. Keying it on delivered events would leave a connection that is open but idle -- an ordinary state for a filtered jetstream consumer -- compounding its backoff. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>