fix: tolerate clock skew when verifying JWTs (leeway 60s)

A client whose clock is a little fast could not connect at all: the MNP
handshake verified the hub-issued token with no leeway, so a token whose
`iat` was a few seconds ahead of the node's clock failed with "the token
is not yet valid (iat)". Seen against a freshly-resumed VM guest.

`meshbay_common.handshake.JWT_LEEWAY_SECONDS = 60` is the shared value;
applied to the handshake, the node's own hub-token decode, revocation-token
verification, and the hub's access-token decode. 60s absorbs NTP-level skew
without meaningfully widening the window on a stolen token (they already
carry a jti and an exp).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

1 files changed, 3 insertions, 1 deletions

diff --git a/packages/meshbay-node/src/meshbay_node/hub_client.py b/packages/meshbay-node/src/meshbay_node/hub_client.py
index 1e975fa..8873958 100644
--- a/packages/meshbay-node/src/meshbay_node/hub_client.py
+++ b/packages/meshbay-node/src/meshbay_node/hub_client.py
@@ -129,7 +129,9 @@ class HubClient:
 
         access_token = data["access_token"]
 
-        decoded = jwt.decode(access_token, hub_pk_pem, algorithms=["EdDSA"])
+        from meshbay_common.handshake import JWT_LEEWAY_SECONDS
+        decoded = jwt.decode(access_token, hub_pk_pem, algorithms=["EdDSA"],
+                             leeway=JWT_LEEWAY_SECONDS)
         # No pk_user claim to check any more: tokens carry no key. What binds this
         # token to this node is the Ed25519 challenge it was issued against.
         assert "jti" in decoded, "Hub token missing jti — hub is outdated"