renderer: a read that asks for fresh data, or any read after a mutation, no longer answers from the 1s GET dedupe cache

[kai-openswarm]

What

The renderer's fetch interceptor (frontend/src/shared/config.ts) dedupes identical GETs to the local API through a 1 s response cache. Two cases must never be answered from it, and neither was:

• a caller that asked for fresh data (cache: 'no-store' / 'reload') — it now bypasses the cache and an identical in-flight request;
• any GET after a successful mutation that may have changed what it reads — every mutation now clears the GET cache (it is a burst dedupe, not a store; the cost is at most one extra round trip per URL).

The policy lives in a small pure module (getCachePolicy.ts) with a node --test file, so it is testable without a window.

Why (user-visible)

Settings › Memory: add a fact within about a second of opening the tab and the list stays on "Nothing saved yet" even though the store already holds the fact — the panel's post-save refresh() GET was served from the panel's own mount GET, cached moments earlier. Reopening the tab showed it. Any panel that mounts, mutates, and refetches the same URL inside a second has the same hole.

How it was verified

• node --test frontend/src/shared/getCachePolicy.test.ts (2 tests) and tsc --noEmit clean.
• On a packaged 1.7.7 build (macOS): opening Settings › Memory and adding a fact immediately shows the fact 3/3 runs with this change; the same steps failed 3/3 without it (the list stayed empty until the tab was reopened).

No behaviour change for default reads: bursts of identical GETs (twenty cards mounting) still dedupe exactly as before.