[TalhaHunter101]

Fixes #204

Summary

#192 changed cachingSetCacheControlHeader to apply the configured Cache-control directive only for statusCode >= 200 && statusCode < 300, setting no-store for all other status codes. As a result, 304 Not Modified responses—including conditional ETag cache hits handled internally by cachingLoadByEtag as well as explicit reply.code(304).send() responses—incorrectly received Cache-control: no-store.

Per RFC 9110 §15.4.5 and RFC 9111 §4.3.4, a 304 response must carry the same Cache-Control directive that a 200 OK response would have included so caches can retain and refresh stored freshness policies.

Changes

• Updated cachingSetCacheControlHeader in index.js to apply the configured Cache-control value when (reply.statusCode >= 200 && reply.statusCode < 300) || reply.statusCode === 304.
• Added unit tests in test/headers.test.js covering both explicit reply.code(304).send() responses and conditional 304 hits served via If-None-Match ETag caching.
• Verified with npm test (26/26 unit tests with 100% c8 coverage + tstyche TypeScript tests) and npm run lint.

Checklist

• run npm run test && npm run benchmark --if-present
• tests and/or benchmarks are included
• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct