fix(briefing): invalidate cached briefing on workspace data change

[Ovaculos]

Summary

The home-dashboard briefing cache was purely TTL-based — adding entities to bundle apps (todos, CRM rows, notes) left the dashboard showing the pre-update briefing for up to the full TTL window. Closes #225.

Invalidation is now content-based. computeBriefingFingerprint signatures the data a briefing is built from — activity logs and each running bundle's entity data (file count, newest mtime, total size) — and BriefingCache.get(fingerprint) serves a stored briefing only while that fingerprint still matches.

Composes with stale-while-revalidate

This branch was rebased onto the stale-while-revalidate (SWR) flow that landed after it was first opened. The two fit together cleanly:

• A data change now misses get() even within the TTL (fingerprint mismatch), instead of waiting out the TTL.
• The dashboard serves the prior briefing instantly via getStale() while a fresh one regenerates in the background — no synchronous wait on the model.
• getStale() is intentionally fingerprint-agnostic: serving a briefly-stale briefing during the regen window is the whole point of that path. The fingerprint check lives in get().

Net effect: a todo added in-app shows up on the next dashboard load, and the load is still instant.

Why a fingerprint, not events

#225 suggested subscribing to data.changed. Event-based invalidation doesn't work here:

• Emitting data.changed from /mcp loops — the iframe widget bridge calls tools over /mcp, so a broadcast triggers a useDataSync refresh, which is another /mcp call, which broadcasts again.
• An in-process notifier avoids the loop but fires on every tool call, including reads. Apps read constantly, so the briefing regenerated on every interaction.

A tool call can't distinguish a read from a write. A content fingerprint invalidates if and only if the underlying data actually changed — no heuristic, no event plumbing.

Coverage

The fingerprint watches data, not the write path, so it is vector-agnostic — agent, iframe widget, external MCP client, and bundle install are all caught. Coverage is by data source:

• Bundle entity data (entityDataRoot) — the issue's core case. This is the same path entity facets read, so the fingerprint signatures exactly the data those facets summarize.
• Activity logs ({wsDir}/logs)
• Bundle install / uninstall (running-bundle set)
• Facets sourced from live MCP resource/tool calls instead of entity files are not fingerprinted; they fall back to the TTL. Documented on computeBriefingFingerprint.

dirSignature uses lstatSync (a dangling symlink is sized, not thrown) and skips entries that vanish mid-walk, so a concurrently-mutating tree cannot crash a briefing.

Test plan

• bun run verify — static, unit, web green
• briefing-cache unit tests (18): fingerprint matching, SWR getStale() semantics, and computeBriefingFingerprint (file add/edit, entity data, non-running exclusion, missing dirs, dangling symlink, symlink-to-dir)
• Manual: add a todo in-app, reload home — briefing reflects it
• Manual: revisit home repeatedly with no change — served from cache, not regenerated