device: add repro for permanent device leak via stale indexTable entry + queue finalizer cycle

[lkosewsk]

This draft adds a failing test (device/leakrepro_test.go) that reproduces a
permanent device leak, so it's easy to check out and run: go test ./device/
-run TestLeak -v. See ./LEAK_REPRO.md for more.

The leak: tearing a peer down while a handshake is in flight can leave a stale
entry in device.indexTable pointing at the removed peer. Since each peer's
autodraining queues carry a finalizer that captures *device
(runtime.SetFinalizer(q, device.flushInboundQueue) in channels.go), that stale
device → peer → queue → finalizer → device reference is a cycle containing a
finalizable object, which Go never collects. The whole *Device leaks — its 64
KiB PopulatePools buffers and everything else. It's permanent (not
timer-bounded), leaks no goroutine, and -race stays silent, so it's easy to
miss; the symptom is unbounded RSS growth when devices are repeatedly brought
up and torn down (e.g. a tsnet Server.Close() that races an in-flight
connection).

Why it happens: Peer.Stop() early-returns on !isRunning, so its indexTable
cleanup (ZeroAndFlushAll) only runs on the first stop. Meanwhile registering
an index entry (SendHandshakeInitiation → CreateMessageInitiation, and
Timer.Mod) is guarded by timersActive() but not atomic with Stop(), so a
handshake send — directly, or via a leaked pending handshake timer firing
after the stop — can register a fresh entry after the cleanup ran. isRunning
is now false, so no later Stop() ever clears it.

The tests pin down the mechanism:

• TestLeak_PermanentFinalizerCycle — clean removal collects; a handshake (or
  even a bare index entry with no crypto) leaks; clearing the queue finalizers
  frees it either way.
• TestLeak_DoesNotSelfHeal — handshake timers re-pin permanently when they
  fire; keepalive/zero-key timers self-heal.
• TestLeak_StopRace — racing a real handshake send against Stop() hits the
  leaked state ~32k/100k iterations; clean under -race.

Likely fix suggested by Claude (not included here — this is just the repro): clear the peer's
indexTable entries unconditionally on removal (in
removePeerLocked/RemoveAllPeers) instead of relying on Stop()'s
isRunning-gated path, so the device → peer edge can't survive removal.

[bradfitz]

A finalizable object trapped in a reference cycle is never collected by Go

nit: Go’s docs say this is not guaranteed, not formally "never".

"Finalizers are run in dependency order: if A points at B, both have finalizers, and they are otherwise unreachable, only the finalizer for A runs; once A is freed, the finalizer for B can run. If a cyclic structure includes a block with a finalizer, that cycle is not guaranteed to be garbage collected and the finalizer is not guaranteed to run, because there is no ordering that respects the dependencies."