[T3 Connect] Stop re-signed websocket tokens from outliving the original

[bradleyshep]

Part of the work to move T3 Code's T3 Connect relay onto SpacetimeDB.

Description of Changes

/v1/identity/websocket-token re-signed any token it accepted, including its own copies, with a fresh iat and an exp 60 s out. So re-signing each copy before it expired renewed a token forever, and a module could never tell when the underlying session token was actually issued (for example, to refuse tokens older than a couple of minutes).

The re-signed copy now keeps the original iat and expires within 60 s, but never after the original token's exp. A token with no exp still gets one 60 s out.

This came out of #6006; it wasn't carried into the split PRs (#6009–#6013) because it's a server behaviour change rather than an SDK fix.

API and ABI breaking changes

None to the API. Two behaviour changes:

• A client that relied on repeatedly re-signing a short-lived token to keep it alive now has to obtain a fresh token from its issuer instead.
• Modules see the original token's iat instead of the re-sign time. That applies to every connection the TypeScript SDK makes with a token (it always swaps the token through this endpoint, in browsers and Node), and to the Rust SDK's browser build and C#'s WebGL build.

Rollback safety impact

n/a

Expected complexity level and risk

1. It only changes which iat/exp the re-signed claims carry.

Testing

• New test re_sign_never_extends_a_token: a token expiring in 30 s re-signs to a copy with the same iat and exp (the old code gave it a fresh 60 s); a token with no expiry gets one within 60 s (allowing JWT whole-second rounding); re-signing that copy again keeps its iat and exp instead of renewing it
• cargo test -p spacetimedb-client-api --lib auth (7 passing, five runs in a row)
• rustfmt --check
• Reviewer: check whether any first-party client depends on renewing re-signed tokens