Add expiry to HMAC-signed download tokens, with 30-day default TTL

bmersereau proposed adding an `exp` Unix timestamp to every HMAC-signed download token and rejecting tokens past their expiry on verification. Legacy tokens without `exp` remain valid, so nothing breaks on deploy. The PR is open against upstream.

The signing helper gains an optional TTL parameter defaulting to 30 days, baked as an exp field into the signed payload. The verifier checks the field if present and rejects expired tokens with a 401. Tokens minted before this change carry no exp field and continue to pass - a deliberate choice to avoid breaking links already in circulation.

The 30-day window is defended in the PR as a practical balance: long enough for links shared in chat history to stay usable, short enough to limit exposure if the signing secret is rotated.

vitest lands in the backend as part of this PR, with unit tests covering the full token lifecycle: round-trip sign-and-verify, tamper rejection, presence of the exp claim in newly minted tokens, expired-token rejection, and the still-valid path at one second before expiry.