[linyiru]

The byte caps alone left two costs unbounded:

• A write-scoped job could finalize any number of empty entries. Each one stays in the index, gets rewritten with it under the lock, and is scanned on every lookup.
• A lookup could name any number of restore keys, each costing two scans of every entry under the lock.

Changes:

• Keys: requests keep to @actions/cache's own limits: ten keys in all, each at most 512 characters, counted in characters. A request past them gets 400.
• Per repository: at most --max-repo-entries entries (default 2000). Past it, a new reservation evicts that repository's own least-recently-used entry, so one repository cannot flush the others.
• Per host: at most --max-entries entries (default 20000).
• Per job: at most 64 unfinished uploads, because reservations are never evicted. Past that, or once reservations alone fill a cap, the create gets ok:false. The toolkit turns that into a warning, not a failed job.
• Eviction: it sorts once, so trimming a large index is not quadratic. It runs after a stale reservation is reclaimed, so a create for an existing key evicts nothing.

Tests are in internal/cacheserver/entrylimit_test.go. scripts/mutate.sh confirmed that each of these is caught by a test: the repository filter, the job reservation cap, the LRU order, the reservations-only refusal, the key count and the character count.

Review: a fresh reviewer agent reviewed the first version. Its main finding was that a host-wide count alone let one job evict every repository's cache and then block all saves. That led to the per-repository and per-job caps here. Its other should-fixes are fixed too: the quadratic eviction, the check running before the reclaim, and keys counted in bytes. Left for later: saving the whole index on every lookup hit.