docs(readme): mention Retry-After 429 header alongside RateLimit-* (#325)

#322 exposed `Retry-After` on cross-origin 429 responses so browser
JS could honor the server's back-off instead of falling back to a
fixed-delay retry. The README's "HTTP conventions" section listed
the RateLimit-* trio but never mentioned Retry-After, so SDK
authors reading the doc wouldn't know the field was available.

Add a bullet describing the header, what it means, and the CORS
exposure rationale (Retry-After is NOT on the CORS safelisted-
response-headers set, so the project's expose-headers list is what
makes it readable cross-origin).

Co-authored-by: Aaron K. Clark <akclark@thenetwerk.net>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: 3 people

README.md

@@ -66,6 +66,11 @@ Working example at [node.timetrackerapi.com](http://node.timetrackerapi.com).
   propagate trace context from a reverse proxy / mesh.
 - **`RateLimit-*` (response headers, RFC standard)** — `RateLimit-Limit`,
   `RateLimit-Remaining`, `RateLimit-Reset` on every /v1/* response.
+- **`Retry-After` (response header on 429, RFC 7231)** — seconds the
+  client should wait before retrying when the quota is exhausted.
+  Cross-origin browser JS can read this via the CORS expose-headers
+  list (it's not on the CORS safelist) so SDKs can honor the server's
+  back-off instead of falling back to a fixed-delay retry.
 - Browser JS reading any of the above on a cross-origin response works
   out-of-the-box: the CORS layer's `Access-Control-Expose-Headers` covers them.