HTTP cache revalidation: prevent 304 Not Modified when client JWT has expired

## Objective

Ensure `GET /api/v1/status-lists/{list_id}` does not return `304 Not Modified` with an empty body when the client's previously cached Status List Token has expired.

## Context

When a client queries a status list with an `If-None-Match: ` header, the server validates the ETag against the current database version. If the list has not changed, the server returns `304 Not Modified` with an empty body.

However, if the client's cached JWT token has reached its `exp` time, the client receives no body and is left with an expired, unusable token. Per RFC 9110 §8.8.1, a weak validator should change when the cached representation is no longer an acceptable substitute, and Draft-21 §8.2–8.3 requires valid tokens for relying party verification.

## Deliverables

- [ ] Update conditional revalidation logic in `src/server/handlers/status_list/get_status_list.rs` and `conditional.rs` to take token expiration into account.
- [ ] Factor token expiration window into ETag generation or evaluate token expiration before returning 304.
- [ ] When the cached token would be expired, bypass the 304 response and return a fresh `200 OK` with a newly signed Status List Token.
- [ ] Add automated tests with simulated time advancement verifying that revalidation with an expired token yields a fresh 200 OK response.

## Acceptance Criteria

- [ ] Revalidation of an expired token returns `200 OK` with a newly signed, valid token instead of `304 Not Modified`.
- [ ] Revalidation within the token's validity period continues to return `304 Not Modified` efficiently.

## References

- `src/server/handlers/status_list/get_status_list.rs`
- `src/server/handlers/status_list/utils/conditional.rs`
- Arc review: `arc-review/finalReview/application-functional-bugs/README.md` (PoC 4)
- RFC 9110 §8.8.1 & Draft-21 §8.2–8.3