Notify about missing local network access, and stop misdiagnosing it

[kasnder]

Stacked on #707, which is stacked on #704. Review those first; each retargets automatically as the one below it merges.

The problem

After #704 and #707, everything that tells the user about missing local network access requires them to already be in the app:

Surface	Reaches the user when…
Warning row on the main screen	they open the app
Settings prompt	they happen to be changing dns, doh_*, wg_*, socks5_* or tethering mode
Log.w in ServiceSinkhole	someone reads a bug report

But the symptom is "nothing resolves", and nobody attributes that to a permission. The likely responses are to turn the VPN off or uninstall — neither of which the app ever hears about.

Worse, the notifications that do fire today point at the wrong thing. A LAN resolver we are not allowed to reach raises the DoH one:

Secure DNS (DoH) cannot be reached even though you have an active internet connection. If this happens repeatedly, consider disabling it in the Network settings.

That blames DoH and recommends disabling a feature that works fine. A WireGuard peer on the LAN likewise sends the user into the WireGuard settings for a problem that is not there.

The change

• A NOTIFY_LOCAL_NETWORK notification, raised from the same place as the existing Log.w — where the tunnel is built — and cleared as soon as the permission is granted. setOnlyAlertOnce, since the tunnel is rebuilt on every network change. Tapping it opens the main screen, where the warning row requests the permission.
• showDohErrorNotification() and showWireGuardErrorNotification() check isMissing() first and defer to it, so the user gets the actual cause and a one-tap fix instead of misleading advice.

Follows the established pattern of NOTIFY_DOH_ERROR / NOTIFY_WG_ERROR: same channel, same category, same VISIBILITY_SECRET.

The notification is an additional channel, not a replacement for the warning row — POST_NOTIFICATIONS may itself be denied, which is what the other row exists for.

Testing

On a Pixel 8 (Android 17, API 37), notification permission granted:

• Custom DNS at 192.168.178.50, permission denied, VPN enabled — notification posted, title Local network access needed, body naming the cause and what to tap.
• Permission then granted and the tunnel rebuilt — notification gone.
• DoH at https://192.168.178.128:8443/dns-query, permission denied — the user gets Local network access needed; the misleading "Secure DNS cannot be reached … consider disabling it" is not posted.
• Negative control: DoH at https://192.0.2.1/dns-query with the permission granted — the DoH notification posts as before, once the proxy's failure threshold trips. The substitution has not swallowed the genuine DoH case.

One honest limit: in the third scenario both the tunnel-build path and the showDohErrorNotification() guard have the same trigger condition and post the same notification, so which of the two posted it is not distinguishable from outside. What is verified is the user-visible property — the correct message appears and the misleading one does not.