Bump to v1.6.0: peer-address recovery, reconnect crash, long-run memory/CPU leak

Three reliability fixes. Wire format and audio pipeline unchanged from
v1.4 / v1.5 — all interoperate.

Peer address recovery:
* When a tracked peer goes Unreachable (its resolved address — often a
  stale DNS / Pi-hole record, or a peer that rebooted onto a new IP) but
  the same peer is still heartbeat-pinging us from a different address,
  RemSound now adopts the live address instead of transmitting to a dead
  one. HeartbeatService records untracked ping sources; MainForm's
  TryAdoptLiveHeartbeatAddress (1 Hz) re-points the sender, heartbeat
  tracking and receiver allow-list. Conservative: fires only on the
  unambiguous one-unreachable-and-one-source case, private-range (RFC1918)
  addresses only so a relay can't hijack the sender, 10 s cooldown.

Reconnect crash:
* Fixed IndexOutOfRangeException in MainForm.SyncConnectedList. A churny
  peer-list rebuild (peer reboot) left SelectedIndex pointing past the
  rebuilt item array; the 1 Hz status timer read SelectedItem and crashed
  the app. New SafeSelectedItem bounds-checks the index; applied to all
  three timer-driven sync methods. The status tick is also wrapped in
  try/catch so a transient WinForms hiccup logs instead of crashing.

Long-run memory / CPU leak:
* A receiver left running for hours grew to gigabytes and climbing CPU.
  Decoder sessions orphaned by peer reconnects were not reaped — every
  reconnect mints a fresh (endpoint, streamId) key, and PruneIdleSessions
  silently skipped sessions whose PlayoutEngine lookup missed. Rewrote it
  to reap on each session's own LastWriteUtc (no cross-dictionary lookup),
  added a hard MaxLiveSessions cap as a backstop, and a "stream sessions
  live: N" diagnostic line. Bounds both memory and render-thread CPU.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

readme.html

@@ -931,6 +931,9 @@ Bind whatever key combinations you prefer (e.g. Ctrl+Shift+Up / Ctrl+Shift+Down
 <li>Check Windows Firewall isn&rsquo;t blocking RemSound. The first launch usually prompts; if you said no, you&rsquo;ll need to allow it manually.</li>
 </ul>
 
+<h3>A peer rebooted or changed IP and audio didn&rsquo;t come back</h3>
+<p>As of v1.6, RemSound follows a peer to its current address on its own. If the address you connected to stops responding but the same peer is still reaching RemSound from a different address on your network &mdash; because they rebooted onto a new IP, or their computer name resolved to a stale address &mdash; RemSound re-points to the live address within a few seconds and audio resumes without you touching anything. If it doesn&rsquo;t recover, the peer is genuinely unreachable (off, asleep, or a firewall is blocking the new path).</p>
+
 <h3>One side says &ldquo;unreachable&rdquo; even though audio is flowing</h3>
 <p>Heartbeat shares the audio port, so if audio gets through, heartbeat should too. If one side is showing &ldquo;unreachable&rdquo; while audio plays, make sure both machines are running the same RemSound build &mdash; an older version on either end can speak a different heartbeat dialect.</p>