[Security 7/9] Download-token expiry (with legacy back-compat)

From the PR description

[Security 7/9] Download-token expiry (with legacy back-compat)

Part of the split of #227 into single-topic PRs. Index: tracking comment on #227.

TL;DR

Download links are HMAC-signed tokens encoding an R2 path + filename. This PR adds a mandatory exp claim to every newly issued token (30-day default TTL) and rejects expired or malformed-exp tokens. Well-signed legacy tokens without an exp claim are accepted transitionally so historical links baked into chat history don't 404 on deploy.

Risk to user data

Severity: medium-high. A non-expiring download token is a permanent capability. In a legal product it points at a confidential document, and it leaks the way URLs always leak - chat logs, browser history, forwarded emails, referrer headers. A leaked eternal link is a confidential document exposed forever, to anyone who ever sees the URL. Time-boxing bounds that exposure window.

Flows affected

• Download link issuance (signDownload / signDownloadPayload).
• /download/:token verification (verifyDownload / verifyDownloadPayload).
• Links persisted in historical chat messages (the back-compat concern).

Attack precedent

The general principle - credentials must be time-boxed - is codified for signed tokens in RFC 8725 (JWT BCP): always set and validate exp. Long-lived bearer URLs are a recurring source of data exposure (leaked pre-signed S3 URLs, permalink leaks via referrer).

Possible fixes, and what we chose

flowchart TD
    T["/download/:token"] --> S{HMAC signature valid?}
    S -- no --> Rej["reject (404)"]
    S -- yes --> E{has exp claim?}
    E -- "yes" --> V{exp well-formed<br/>and in the future?}
    V -- yes --> OK["serve file"]
    V -- "no / expired / malformed" --> Rej
    E -- "no (legacy)" --> OK2["serve file<br/>(transitional back-compat)"]

Disclosed trade-off: accepting legacy exp-less tokens is a deliberate, temporary compromise, called out in-code. The intended end state is strict exp enforcement once historical links have aged out or been re-issued on access - a one-line tightening. downloadTokens.expiry.test.ts locks in all four behaviours: fresh accepted (exp present), legacy accepted, expired rejected, tampered/malformed-exp rejected (including stripping exp as a tamper route). This PR reflects the reviewed final policy (the strict-then-relaxed history from #227 is collapsed into the transitional policy plus its tests).

What's in this PR

• backend/src/core/downloadTokens.ts - new signer/verifier with exp, timing-safe compare, legacy branch.
• backend/src/lib/downloadTokens.ts - delegates to core; doc header reflects the policy.
• Tests: downloadTokens.expiry.test.ts (7 tests).

Reading

RFC 8725 (JWT Best Current Practices) · OWASP Access Control Cheat Sheet