Historical status list tokens: correct iat and validity duration

## Objective

Ensure historical status list token responses (`GET /api/v1/status-lists/{list_id}?time=...`) set `iat` to the current signing timestamp and generate valid non-expired tokens.

## Context

When responding to historical status list queries (`GET ?time=`), `handle_historical_request` in `src/server/handlers/status_list/get_status_list.rs` loads the historical snapshot, generates a new cryptographic signature, but sets the token's `iat` and `exp` claims to the snapshot's past timestamps (`snapshot.iat`, `snapshot.exp`).

Per OAuth Status List Draft-21 §5.1, `iat` MUST be the time at which the Status List Token was issued. When `snapshot.exp` is in the past, the newly signed token is already expired upon delivery, causing relying party verifiers to immediately reject it.

## Deliverables

- [ ] In `handle_historical_request` (`get_status_list.rs`), set `iat` to the current timestamp (`now`) when the token is signed.
- [ ] Calculate `exp` from the current time using the configured token lifetime (`now + token_exp_secs`).
- [ ] Ensure the token payload correctly represents the historical snapshot's bit flags and list content at time `T`.
- [ ] Add tests verifying that historical status list tokens have `iat <= now < exp` and pass standard cryptographic and expiration verification.

## Acceptance Criteria

- [ ] Historical status list tokens have valid `iat` and `exp` claims at the time of issuance.
- [ ] Verifiers do not reject historical tokens as expired upon receipt.
- [ ] Conforms to OAuth Status List Draft-21 §5.1 and §8.4.

## References

- `src/server/handlers/status_list/get_status_list.rs` (lines 146–185)
- Arc review: `arc-review/finalReview/protocol-compliance/README.md` (PoC 7)