feat(api): revalidate the collection cache against disk on read

[simoncodes-ca]

Closes #86

Problem

The app serves a collection from an in-memory tree that it patches as the UI mutates
resources. CLI commands write straight to resource_entries.json / tracker_meta.json and
never tell a running app, so the cache goes stale — and a browser refresh does not fix it,
because the page re-reads the same server-side cache. Only a restart does. Users reasonably
read that as data loss.

Why not the two approaches in the issue

Both have a WSL failure mode, and both miss changes that do not come from the CLI.

Approach	WSL failure mode
CLI → POST /invalidate	CLI in WSL, app on Windows (or vice versa) → localhost is not shared. WSL2→Windows host needs the gateway IP from /etc/resolv.conf, or Win11 22H2+ mirrored networking. Silent no-op exactly when it matters.
fs.watch / chokidar in the API	Windows-side writes on /mnt/c (drvfs/9p) never raise inotify events in WSL — microsoft/WSL#4739. The watcher looks healthy and fires nothing. Same on several network and container mounts.

Neither sees a git checkout, a branch switch, or a hand edit.

What this does instead: revalidate on read

Before serving the tree, the cache status, or a search, the API takes a stat-only
fingerprint of the collection's translations folder and compares it with the one recorded at
index time. A mismatch drops the cache, so the request answers 202 Accepted and the next
one returns fresh data. The existing not-ready → async reindex → UI retry protocol does the
rest, so the Tracker UI needed no change.

• computeTreeFingerprint() (libs/core/src/lib/resource/tree-fingerprint.ts) walks the
  folder with readdir + stat only, returning {fileCount, folderCount, totalSize, maxMtimeMs}. Counts and size sit alongside mtime because mtime granularity is as coarse
  as one to two seconds on drvfs and FAT, so a same-second edit can leave mtime untouched.
• CollectionCacheService.revalidate() is throttled to 2000 ms, configurable via
  LINGO_TRACKER_REVALIDATE_INTERVAL_MS.
• The API's own writes re-take the baseline on the next tick, coalesced, so a bulk endpoint's
  per-resource cache patches cost one scan rather than one per resource — and the app never
  reads its own write as somebody else's.

No new dependency, no watcher, no port resolution, no daemon. Behaves identically on macOS,
Linux, Windows, WSL, containers and network shares.

Verified end to end

Built API run against a scratch project on port 3931:

Action	Result
add-resource via the CLI	new key served on the next fetch, no restart
POST /resources via the API	no false invalidation — invalidation and index counts unchanged
Hand edit of resource_entries.json	detected, edited value served

Suites green: core 1227, api 200, tracker 493, plus cli and domain. pnpm lint and
pnpm typecheck clean.

[lingo-tracker-release]

🎉 This PR is included in version 0.18.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀