fix(uxcore): make new-update modal dismissal stick

[MaryWylde]

Summary

• Closing the new-update modal now persists in localStorage keyed to the CMS updatedAt, so it stays dismissed across refreshes, closed tabs, and browser restarts.
• Publishing a new update in Strapi (changed updatedAt) shows the modal again exactly once; Frontend modal visibility and Appears after x seconds keep controlling opening as before.

Test plan

• Playwright browser test against the dev server with mocked CMS payload: modal appears after the configured delay, closes, stays hidden after reload and after closing/reopening the tab, and re-shows when updatedAt changes.
• After release: close the modal on production, reopen keepsimple.io in a new tab, confirm it stays hidden.

🤖 Generated with Claude Code

[github-actions]

Claude finished @MaryWylde's task in 45s —— View job

---

Review: fix(uxcore): make new-update modal dismissal stick

• Gather context (read diff, related files)
• Understand the request
• Review correctness / React best practices
• Review TypeScript quality
• Review project conventions (AGENTS.md)
• Review SSR/hydration safety
• Post final review

Change: swaps sessionStorage → localStorage for the uxcoreNewUpdateDismissed key in NewUpdateModalContainer.tsx (2 call sites), so dismissal persists across tabs/restarts instead of just the session, matching the PR description.

Assessment: looks correct, minimal, and safe to merge.

• Both localStorage accesses (read at line 29, write at line 55) happen inside useEffect/an event handler, never at module top level — no SSR/hydration risk.
• The read on line 29 is inside the existing outer try/catch (line 20–43), so a thrown localStorage.getItem (e.g. storage disabled) is caught, just logged under the slightly misleading [new-update] fetch failed message — pre-existing pattern, not introduced by this diff, not worth blocking on.
• The write on line 55 already has its own dedicated try/catch for private-mode/unavailable storage — good defensive handling, unchanged by this PR.
• Confirmed DISMISSED_KEY isn't referenced anywhere else in the codebase, so there's no stale-sessionStorage-value migration concern.
• Comment above line 27 was updated to reflect the new persistence semantics ("until site data is cleared") — accurate.
• No AGENTS.md violations: no new deps, no Tailwind/CSS-in-JS, no App Router patterns, storage access stays out of module scope.

No blocking issues found. Nice, tightly-scoped fix.