fix(store): never write the ledger from a snapshot older than the file

[Fishsb]

What this fixes

Two TaskStore instances can point at the same ledger file. That happens in practice whenever the plugin is hot-reloaded: the previous generation's long-lived callbacks (the whenIdle() settlement watchers and the 4-second session scan) keep running against the store instance they captured at load time.

Because a store caches its snapshot forever — load() returns early once loaded === true — and mutate() persists the whole document, the stale instance's next write rolled every commit the newer instance had made back off the file:

• no error is raised,
• the revision does not move backwards (each instance keeps its own counter), so subscribers and the GUI observe nothing,
• the loss only surfaces later as silently missing comments / execution records.

The change

mutate() re-reads the file when it has moved ahead of the cached copy, so a cached snapshot is never authority over a newer document.

async refreshIfStale(): Promise<boolean> {
  const parsed = JSON.parse(await readFile(this.file, 'utf8'))
  if (parsed.revision <= this.ledger.revision) return false   // already current
  this.loaded = false
  this.loadPromise = undefined
  await this.load()                                           // re-adopt via loadOnce
  return true
}

Guarded on revision monotonicity, so the common path (single writer, up to date) is a no-op with no extra I/O.

Why here rather than at the call sites

The plugin has ~30 store.mutate() call sites across execution, session-sync, routes and tools. Fixing this by adding an "am I still the owner?" check to the long-lived services leaves the request-scoped writers (routes/tools) exposed, and quietly re-breaks the moment someone adds a new write path. The store itself is the only place that sees every writer.

Verification

• tests/store-staleness.spec.ts — 3 new tests: the rollback itself, the return value / no-op contract, and revision monotonicity across interleaved writers.
• Two of the three fail with this change reverted (verified by removing the refreshIfStale() call and re-running), so they pin real behaviour rather than restating the implementation.
• Full suite: 354 passed / 25 files.
• npm run typecheck clean; npm run build regenerates lib/ (included, since lib/ is tracked).

Note on scope

This is deliberately one self-contained fix. While diagnosing it I also found two neighbouring issues — reconcile() marking all in-flight runs failed on every load (including hot reloads, whose agents are still alive), and isStaleClaim() measuring how long a claim has been held rather than execution silence. Both are separate; I'll open them individually rather than bundling unrelated behaviour changes here.

[Fishsb]

For the two neighbouring defects I found while diagnosing this, I opened separate issues rather than widening this PR:

• reconcile() marks all in-flight executions failed on every load, including hot reloads #39 — reconcile() marks all in-flight executions failed on every load, including hot reloads whose agents are still alive.
• isStaleClaim() measures claim age, not execution silence, so long-running tasks are mislabelled 认领超时 #40 — isStaleClaim() measures claim age rather than execution silence, so any task running longer than 30 minutes is labelled 认领超时.

Landing this one first is useful for #39: adoption (keeping surviving runs alive across generations) widens the window in which two store instances coexist, which is exactly the failure this PR removes.