[Dodothereal]

What changes

When a request has an X-Amz-Date timestamp outside the ±15 minute clock skew window, ExtendDB returned UnrecognizedClientException with the generic message "Signature expired: the signature is too old or the request date is too far in the future.".

Amazon DynamoDB returns InvalidSignatureException (HTTP 400) with specific messages indicating the direction and boundary times compared against the server clock:

• Past skew (>15 min earlier):
  Signature expired: <date> is now earlier than <edge> (<server_time> - 15 min.)
• Future skew (>15 min later):
  Signature not yet current: <date> is still later than <edge> (<server_time> + 15 min.)

This PR updates validate_timestamp in crates/auth/src/sigv4/verify.rs to return InvalidSignatureException with the directional messages and adds format_iso8601_basic.

Measurements

As reported and measured by the issue reporter in #805 against Amazon DynamoDB in us-east-1 on 2026-11-03 (and referenced in PR #792):

• 16 min before server clock: 400 InvalidSignatureException Signature expired: 20261103T201550Z is now earlier than 20261103T201650Z (20261103T203150Z - 15 min.)
• 16 min after server clock: 400 InvalidSignatureException Signature not yet current: 20261103T204750Z is still later than 20261103T204650Z (20261103T203150Z + 15 min.)

(Note: Live AWS measurements were not performed in this workspace; they are cited directly from the reporter's findings in #805).

Tests & Validation

• Added unit tests in crates/auth/src/sigv4/verify.rs:
  • validate_timestamp_expired_returns_invalid_signature_exception: verifies exact Signature expired error code and text format against known epoch.
  • validate_timestamp_future_returns_invalid_signature_exception: verifies exact Signature not yet current error code and text format against known epoch.
  • validate_timestamp_at_exact_boundaries_succeeds: verifies exact ±15 minute boundary timestamps are accepted.
  • validate_timestamp_live_clock_succeeds_for_now: verifies current timestamps validate cleanly against system clock.
• Local test execution: cargo test -p extenddb-auth (441 unit tests, 3 doctests passed).
• Code formatting & linting: cargo fmt --check and cargo clippy -p extenddb-auth --all-targets -- -D warnings passed cleanly.

CONTRIBUTING & RFC / Auth Policy Note

Under CONTRIBUTING.md, an RFC is requested for changes to wire protocol or authentication/authorization. Meanwhile, docs/rfcs/README.md notes that an RFC is not required for bug fixes, dependency bumps, internal refactors that preserve public behavior, documentation, or tests.

This PR does not alter ExtendDB's authentication model, the 15-minute window threshold, or the constant-time pipeline invariants. However, because it alters the returned error type and message for out-of-skew requests on the wire, this PR is submitted as a draft to seek maintainer review on whether this bug fix falls under standard bug fix treatment or requires an RFC or ADR.

Provenance & Disclosure

• Developed with AI assistance (Gemini 3.8 Flash via T3 Code harness).
• Verification was conducted purely locally on test fixtures; no live cloud resources or AWS accounts were utilized.

Checklist

• I have read CONTRIBUTING.md
• All tests pass (cargo test -p extenddb-auth)
• Code is formatted (cargo fmt --check)
• Clippy is clean (cargo clippy -p extenddb-auth --all-targets -- -D warnings)
• Added unit tests for new functionality
• No new dependencies or cost/credential requirements
• Draft PR for maintainer review