Clients do not promptly observe loss of DERP connectivity in some scenarios

### What is the issue?

There are some conditions under which a Tailscale client will not correctly identify that a connection a/it's home DERP has been lost. Failing to identify this state results in loss of connectivity with peers if it also coincides with endpoint changes or is behind a hard to traverse NAT as in the reproduction example.

### Steps to reproduce

On a macOS node, connect via wifi to a residential internet connection with both IPv4 and IPv6 network access. Assert that Tailscale is operating normally.

Use the wifi connection menu to switch to an iOS device tethering to a cellular connection.

Observe that the client reconnects to control, informs control of new endpoints, but the client has not reconnected to a new home DERP and both control and derptrack observe the old DERP client endpoint still "active" for the node.

Observe that connections to the client fail unless they can directly reach one of the clients new endpoints.

### Additional Notes

- We shouldn't resolve this just by unconditionally severing DERP connectivity as there are many cases of route changes/interface changes where doing so may be unnecessarily disruptive.
- A core part of this issue stems from having unidirectional keepalives on the DERP connection - they come from the server ticks, and the client is not tracking/enforcing their frequency.
- After a major network change the client _should_ perform some kind of active assertion on the DERP connection to trigger teardown if it is no longer viable. Something like a ping frame is fine.

### Are there any recent changes that introduced the issue?

Not that I know of.

### OS

macOS

### OS version

15.3.2

### Tailscale version

1.83.81

### Other software

_No response_

### Bug report

See https://github.com/tailscale/tailscale/issues/10701 for some related reports.