feat: implement historical resolution

[Ngha-Boris]

Summary

Support point-in-time status queries: let a consumer ask for a token's status "as of" a past date, not just "now." OPTIONAL in draft-21 - deferred from the compliance audit, tracked here.

Background

The status endpoint only answers the current status. Some use cases need to prove what a credential's status was at a specific moment (audits, legal disputes, "was this valid when the contract was signed?"). draft-21 §8.4 defines a ?time=<unix-timestamp> query parameter for this.

What's missing

No handling of the time query parameter on the GET status-list route; the server always returns the current Status List Token.

Why / when this matters (build trigger)

Build when an auditor or a compliance/regulatory requirement forces a "status as of date X" question. Niche outside regulated/audit settings - most RPs only care about "valid right now."

Acceptance criteria

• GET /statuslists/{id}?time=<ts> returns the Status List Token valid at <ts>.
• If the parameter is unsupported → 501 Not Implemented; if the requested time isn't available → 404 Not Found (§8.4).
• Returned token's iat..exp window actually covers the requested <ts> (spec requires the client to reject otherwise - don't hand back a token that fails that check).
• Note §12.7 privacy considerations (historical queries can leak timing).
• Tests for a valid past-time hit, unsupported-param, and unavailable-time.

References

• draft-21 §8.4 (historical resolution), §12.7 (privacy)
• Compliance matrix row 18 (docs/compliance_matrix.md)

[martcpp]

will check this today

[martcpp]

@Ngha-Boris resolve the conflict thanks

[Hermann-Core]

@Ngha-Boris Comments will be posted for your attention. Please also resolve the merge conflicts.

[Hermann-Core]

The historical resolution implementation (draft-21 section 8.4) has good structure and correctly implements the time-window query logic, but contains three blocking bugs and one important operational concern: Blocking Issues: 1. Missing time parameter validation — Accepts negative, future, or arbitrary past timestamps without bounds, enabling DoS and violating spec intent 2. Historical snapshots lose issuer identity — StatusListHistoryRecord does not store issuer field, causing historical tokens to have empty iss claim and fail verifier validation 3. Missing snapshot retention policy — Snapshots accumulate indefinitely causing unbounded database growth and privacy exposure Important: 4. Privacy considerations — No rate limiting, audit logging, or operator documentation for timing leak risks mentioned in draft-21 section 12.7 Issues #1 and #2 must be fixed before merge (cause validation failures). Issue #3 is operationally critical for production. Issue #4 is a privacy best practice. Also: Please resolve merge conflicts. Tests pass (82 tests) and database query logic is correct (iat <= time < exp half-open interval).

[martcpp]

@Ngha-Boris fix test and other thanks