Fix fork-monitor event cache persistence in GitHub Actions

[jubalm]

Problem

The fork-monitor workflow restores its persisted event cache using the static key event-cache-v1. GitHub Actions caches are immutable: after a cache is created for a key, later jobs cannot replace its contents under that same key.

Repository evidence confirms the main-branch cache (ID 3902983786) was created on 2026-04-22 at 11:01:21 UTC and was still only being accessed on 2026-07-15. Consequently, changes written to public/cache/event-cache.json during later jobs are not persisted for the next run. Each run resumes from the original cache snapshot.

Impact

• Workflow runs can remain green and public fork-risk output is still freshly calculated.
• Incremental event tracking does not advance across runs as intended.
• Repeatedly starting from the old snapshot can increase historical scanning and RPC work.
• Any behavior depending on the latest persisted event-cache state may operate on stale history.

Proposed fix

Use one of these supported cache patterns:

1. Save each updated cache under a unique key (for example, including the run ID or timestamp) and restore the newest matching cache through a stable restore-key prefix.
2. Explicitly delete the prior cache before saving the replacement, with appropriate permissions and failure handling.

The first option follows the normal immutable-cache model and is preferable unless cache retention becomes excessive.

Acceptance criteria

• A run restores the latest cache produced by a preceding successful run.
• The updated event-cache.json is saved under a key that does not collide with an existing cache.
• Fork-risk generation remains fresh and existing risk-monitor/build/deploy behavior remains green.
• Cache retention or cleanup behavior is documented.