feat(mesh): real gateway-to-gateway WireGuard mesh (site-to-site tunnels)

The existing WireGuard code (models/wg_site.js, routes/wireguard.js) is the
roaming-client/exit-node feature -- individual peer configs an admin hands
out, not gateway-to-gateway mesh peering. This adds the latter, per
MULTI_SITE_SPEC.md §4: two theta-gateway instances mesh by one calling the
other's POST /api/mesh/register with a join token (minted via
POST /api/mesh/join-tokens, admin-gated); both sides end up with a live
wg0 peer for the other, mesh-indexed per Appendix A's addressing
(172.24.<idx>.0/16 + 10.<idx>.0.0/16, idx 1-254).

- utils/wg_iface.js: brings up the local interface, preferring in-kernel
  WireGuard (ip link add type wireguard) and falling back to userspace
  wireguard-go when the kernel module isn't available. Both packages
  added to the Dockerfile.
- utils/mesh_addressing.js: pure addressing math, unit tested
  (test/unit/mesh_addressing.test.js).
- models/mesh_gateway.js: Redis-backed registry of known peer gateways
  (same pattern as wg_site.js), assigns + persists mesh indexes.
- utils/mesh_join_token.js: single-use bootstrap credential, same
  GETDEL-on-Redis pattern already used on the theta-directory side.
- routes/mesh.js: /join-tokens (admin), /register (bearer token, no
  session -- called by a remote gateway), /join (admin, initiates from
  this side), /gateways (admin, list).

Verified with a REAL two-container test (not mocked): two independent
containers, each running this actual code, meshed via a live join-token
handshake, brought up real kernel WireGuard interfaces, and passed ICMP
traffic across the resulting encrypted tunnel end to end (0% packet
loss). That test caught a real bug worth calling out: `wg set ... peer
... allowed-ips` only configures WireGuard's own crypto-routing table --
it does NOT add a kernel route for that destination (wg-quick normally
does this as a separate step; we don't use wg-quick). A real encrypted
handshake completed between the two containers with the route missing,
and ping still showed 100% loss until setPeer() was fixed to add the
corresponding `ip route add <allowed-ip> dev <iface>` itself.

nodejs/test/unit/mesh_addressing.test.js

@@ -0,0 +1,27 @@
+'use strict';
+
+const test = require('node:test');
+const assert = require('node:assert/strict');
+const { meshCidrFor, meshAllowedIpsFor, MAX_MESH_INDEX, MIN_MESH_INDEX } = require('../../utils/mesh_addressing');
+
+test('meshCidrFor renders the .1 address in the site\'s /24', () => {
+	assert.equal(meshCidrFor(1), '172.24.1.1/24');
+	assert.equal(meshCidrFor(254), '172.24.254.1/24');
+});
+
+test('meshAllowedIpsFor covers both the mesh /24 and the site\'s 10.x/16', () => {
+	assert.deepEqual(meshAllowedIpsFor(5), ['172.24.5.0/24', '10.5.0.0/16']);
+});
+
+test('rejects index 0 and 255 (reserved) and the out-of-range/non-integer cases', () => {
+	assert.throws(() => meshCidrFor(0));
+	assert.throws(() => meshCidrFor(255));
+	assert.throws(() => meshCidrFor(MAX_MESH_INDEX + 1));
+	assert.throws(() => meshCidrFor(MIN_MESH_INDEX - 1));
+	assert.throws(() => meshCidrFor(1.5));
+	assert.throws(() => meshCidrFor('1'));
+});
+
+test('MAX_MESH_INDEX matches the documented 254-site ceiling', () => {
+	assert.equal(MAX_MESH_INDEX, 254);
+});