Expose rate-limit headers on successful responses

[pavlof01]

Context

apps/api/src/rateLimit.ts returns Retry-After and meta.retryAfter on 429, and nothing before that. A client — including our own frontend — cannot tell it is approaching a limit until it is refused, and an API-key holder has no way to pace themselves.

Proposal

• Emit X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset on successful responses for the bucket the request was charged to.
• Include the bucket name (general / heavy / trace) so a caller can tell which budget the numbers describe.
• Document the headers in the OpenAPI document and in the README's rate-limit section.

Acceptance criteria

• A successful /api/run carries the three headers for the heavy bucket.
• Values are consistent with the 429 the next request would receive.
• Covered in app.test.ts via app.inject().

[wizlor-bfw]

Hi! I'd like to work on this.

One correction to the issue body while investigating: enforceLimit() in apps/api/src/rateLimit.ts already sets X-RateLimit-Limit/-Remaining/-Reset unconditionally (not just on 429) — that part landed in a previous rate-limiting pass. Verified empirically via app.inject() against a mocked successful /api/run.

What's actually still missing, matching the rest of the ask:

• Bucket attribution: a request can spend from more than one budget (general, then heavy on a cache miss); the second enforceLimit() call overwrites the first's headers with no way to tell which budget the numbers describe. Adding X-RateLimit-Bucket fixes that.
• No test coverage asserting these headers on a successful response, or that they're consistent with the 429 a subsequent request would get.
• No documentation — not in apps/api/src/openapi.ts, not in the README's rate-limit bullet.

Plan: add X-RateLimit-Bucket, cover it in rateLimit.test.ts/app.test.ts/app.upstream.test.ts (including a cache-hit-vs-engine-spawn case so the bucket-switch is exercised), and document all four headers in the OpenAPI response headers + README. Opening a PR shortly.