feat: ETag/304 caching on GET /api/tenants (#946)

[Vicistar-V]

Summary

Implements strong ETag / 304 Not Modified caching on GET /api/tenants as specified in issue #946.

Changes

src/middleware/etag.ts

Extended etagMiddleware to honour a pre-set ETag response header while still evaluating If-None-Match through our own strong-comparison logic (RFC 7232 §3.2). Previously, a pre-set ETag caused the middleware to skip all freshness evaluation entirely, letting Express's built-in weak-comparison fresh module incorrectly return 304 for W/"..." tags.

src/routes/tenants.ts

The GET / handler now pre-sets the strong ETag from the tenant list data alone before wrapping it in the response envelope:

ts
res.setHeader('ETag', generateETag(JSON.stringify(tenants)));

This makes the tag stable across consecutive fetches returning the same tenant state, regardless of volatile envelope fields (timestamp, requestId) that change per request.

src/routes/tenants.test.ts

Added focused ETag/304 integration tests:

• 200 with a strong ETag header on first fetch
• 304 when If-None-Match matches exactly
• 200 when If-None-Match doesn't match
• 200 (not 304) for a weak tag — strong comparison only
• 401 for unauthenticated GET
• 500 propagation for repository errors

docs/tenants-api.md

Added GET /api/tenants section documenting ETag format, If-None-Match semantics, comparison rules, and a curl example.

Testing

npx jest --forceExit --testPathPattern="etag|tenants" --no-coverage

80/80 tests pass across all 4 suites.

Closes #946

[drips-wave]

@Vicistar-V Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[greatest0fallt1me]

Great work, this looks good. Thanks for the contribution!