feat(cache): persist read-only API responsesv3.3.1

Add a bounded stale-while-revalidate cache at the Sourcehut API boundary with
stable keys, centralized TTLs, request coalescing, payload hashing, and LRU disk
pruning.

Cache high-value read-only repo, build, ticket, project, profile, paste, and
Home/Work Queue data while keeping mutations network-only and invalidating
related prefixes after successful writes.

Add focused cache tests and implementation notes.

1 files changed, 1 insertions, 1 deletions

diff --git a/Docs/API_CACHE.md b/Docs/API_CACHE.md
index d15b75d..456beb2 100644
--- a/Docs/API_CACHE.md
+++ b/Docs/API_CACHE.md
@@ -8,4 +8,4 @@ TTLs live in `APICacheTTLs`. Active build data uses a very short TTL, mutable ti
 
 Invalidation is intentionally prefix-based. Successful ticket mutations remove ticket, ticket-list, tracker, and Home prefixes. Build retry/cancel/resubmit actions remove build detail, build-list, build-log, and Home prefixes. This avoids a dependency graph while keeping stale post-mutation data out of the high-risk paths.
 
-Known limitations: the first pass is integrated into build detail/logs, ticket detail, README lookup, and repository tree/blob/file reads. Some older list-level paths still use the legacy in-memory cache facade and should move to `APICacheKeys` plus `executeCached` next. Recommended next targets are repository lists, build lists, ticket lists, profile repositories/trackers, and Home/Work Queue sections.
+Known limitations: caching now covers the high-value detail paths plus repository/build/ticket/tracker/paste lists, profile repositories/trackers, projects, and Home dashboard fetches. Some services still perform background refresh one request at a time rather than streaming partial refreshed list pages into the UI, and Work Queue-specific surfaces should be reviewed as a follow-up if they grow beyond the Home dashboard data model.