Added the Refresh All button to invalidate caches and force requests to be sent again

README.md

@@ -19,6 +19,16 @@ Browser extension that adds the "Opportunities Extension" shortcut to the permit
 
 ## CRM Service Request Badges
 
+The header's **Refresh all** button (between theme and Preferences) invalidates
+persisted Products and activity caches and clears in-memory data views. It reloads
+the selected Reference, fetching fresh products and then the permitted SR/Actions
+queries. Customer details, rate cards, consumption charts and AI summaries are
+requested again when opened. Preferences, cookies and authentication are preserved.
+The button is disabled during invalidation and list reload; product/activity badges
+continue to show subsequent background progress. Cache-clear failures are surfaced
+instead of silently reusing cached data, and stale product responses cannot restore
+an invalidated cache.
+
 On the first Opportunities modal opening in a page session, `requestCurrentUser`
 fetches SPA identity before tokenrelay or opportunity requests. Concurrent calls,
 Reference changes and modal reopenings reuse that result. Users with `SALES_REP`
@@ -37,11 +47,19 @@ Records are linked by `OpportunityName_Id_c.OptyNumber`. A green SR badge indica
 one or more matches; its tooltip lists each SR number, title, reported hours, owner,
 email and contact flags. A red badge indicates no match within that query's scope.
 A failed lookup shows `SR ?`, not a false no-match result, and opportunities still load.
-Badges follow Ramp Months. SR results remain in memory only. CRM SR and Actions
-refresh only after actual successful product API requests, not cache reads.
-Cache-only, empty and entirely failed cycles neither query nor clear activities.
-In mixed cycles, Actions refreshes only workloads from fresh products and CRM SR
-refreshes once. Closing and reopening the modal preserves results and does not
+Badges follow Ramp Months. Successful SR and Actions responses are persisted in
+extension local storage, isolated by tokenrelay principal. The cache uses the same
+Preferences lifetime as Products (24 hours by default), anchored to the product
+timestamp rather than the activity response time. Actions entries match each
+product's update; the SR snapshot matches the latest product update in the cycle.
+No credentials, request headers or debug envelopes are stored in this cache.
+Products loaded from cache restore matching activity entries without network calls.
+Missing, expired or mismatched entries are not treated as confirmed empty results;
+they wait for a real product refresh before a new activity query is allowed.
+Empty and entirely failed product cycles do not query activities. In mixed cycles,
+only fresh products permit activity API calls on cache misses; SR refreshes once.
+Activity lookups do not advance the existing Last update timestamp.
+Closing and reopening the modal preserves results and does not
 reload products or trigger these lookups. Already-running product requests may
 finish in the background and update their related activities.
 
@@ -53,7 +71,8 @@ the `WWB-TS` credential in `Wwb-Provider-Authorization`. The Act badge beside SR
 aggregates all products: green means an action's `owner` matches the general
 tokenrelay response's `principal`; red means no matching owner was found. `Act ?`
 means ownership could not be confirmed (including a missing principal). Tooltips
-retain all returned actions, regardless of owner. Principal stays in memory only.
+retain all returned actions, regardless of owner. Credentials stay in memory only;
+the principal is used to scope persisted activity entries.
 Queries are shared per product cycle (up to four concurrently). Reference changes
 that load products from cache do not refresh activities.
 Only the first page is requested for now; `hasNext` is indicated in the tooltip.