Add optional read-only access token to mitigate CREEP (CVE-2025-36852)

[joh-klein]

Implements #12.

What

An optional READ_ONLY_ACCESS_TOKEN (env or --read-only-access-token). When set:

• GET /v1/cache/{hash}: accepted with either token
• PUT /v1/cache/{hash}: requires SERVICE_ACCESS_TOKEN; the read-only token gets 403 Forbidden
• unknown token: 401 as before

This enables the standard CREEP mitigation topology for shared caches: trusted branches (main/release) get the read-write token, untrusted jobs (PR builds) get the read-only one — they still benefit from cache hits but cannot pre-seed/poison entries that trusted builds will consume.

Design notes

• Backwards compatible: without READ_ONLY_ACCESS_TOKEN, behavior is byte-for-byte unchanged.
• Deliberately not support multiple and named service access tokens #4: no named tokens, no per-token buckets/prefixes. Exactly one privilege boundary (read vs write), which was the missing piece identified in the support multiple and named service access tokens #4 review.
• Both tokens are always compared (constant-time ct_eq, as before), so response timing doesn't reveal which token matched.
• Config validation refuses to start if the read-only token is empty or identical to the service token.
• Nothing token-related is logged.
• README gets a short "Protecting against cache poisoning" section (placed after the existing simple config docs — simple first, advanced later); docs/index.html env-var block kept in sync.

Testing

e2e against MinIO, all passing:

case	result
PUT with RW token	202
GET with RW / RO token	200, content identical
PUT with RO token (new or existing hash)	403
GET missing hash with RO token	404
wrong / missing token, any method	401
PUT existing hash with RW token	409
/health without token	200
server start with RO token == RW token	refused with clear error
server start with empty RO token	refused with clear error
no RO token configured	unchanged behavior; former RO token is 401

cargo build + cargo fmt clean.

🤖 Generated with Claude Code