fix(mesh): peer removal now cleans up its kernel routes

wg_iface.removePeer() previously just did `wg set ... remove` -- the
kernel routes setPeer() adds for a peer's AllowedIPs (since wg itself
only configures crypto-routing, not kernel routes -- see setPeer's own
comment) were never cleaned up, a real TODO flagged in code but never
exercised because nothing removed a mesh peer at all.

- removePeer() now queries the peer's current AllowedIPs (`wg show
  <iface> allowed-ips`) BEFORE removing it -- once gone, wg no longer
  knows what to clean up -- and issues `ip route del` for each.
- New DELETE /api/mesh/gateways/:id (models/mesh_gateway.js gained
  remove()) actually calls removePeer(), so the fix has a real caller;
  previously there was no removal path anywhere in the mesh feature at
  all. Refuses to remove the local "(self)" entry. Does not reach out
  to the remote gateway to remove the reciprocal peer -- that side
  needs the same action taken independently.
- Mesh UI: remove button per non-self peer row, using app.messages.confirm
  (not native confirm() -- caught by this repo's own no-native-dialogs
  test, which failed on first pass and is now green).

Verified for real with a live WireGuard interface in a container: routes
for a peer's AllowedIPs present after setPeer, confirmed gone after
removePeer, while the interface's own local route correctly survives.

nodejs/models/mesh_gateway.js

@@ -82,4 +82,13 @@ async function register({ publicKey, endpoint, siteSlug }) {
 	return gateway;
 }
 
-module.exports = { list, findByPublicKey, register, MAX_MESH_INDEX };
+async function remove(id) {
+	const redis = await getRedis();
+	const gw = deserialize(await redis.hGetAll(gatewayKey(id)));
+	if (!gw) return null;
+	await redis.del(gatewayKey(id));
+	await redis.zRem(idxKey(), id);
+	return gw;
+}
+
+module.exports = { list, findByPublicKey, register, remove, MAX_MESH_INDEX };