Add startup state snapshots for fast storage initialization with lazy filesystem backfill

[Copilot]

PR #338 attempted to optimize startup by reusing known partitions/indexes instead of fully rescanning on every open. This change reintroduces that optimization from scratch with a best-effort snapshot model: restore fast when possible, then reconcile lazily with current filesystem state.

• Startup snapshot model

  • Added persisted startup-state file: .<storage>.startup-state.json in indexDirectory.
  • Snapshot contains known partition file names and secondary index names (versioned payload).

• Fast restore on open + lazy reconciliation

  • ReadableStorage.open() now attempts snapshot load first.
  • When snapshot is present/valid, storage opens immediately from known state and kicks off scanFiles() in background to discover drift/new files.
  • When snapshot is missing/invalid, startup falls back to full scan behavior.

• Known-state tracking

  • Added explicit tracking for known secondary indexes (knownIndexes) and unified registration path (registerKnownIndex).
  • Partition/index discovery paths now funnel through known-state update hooks.

• Writable-only persistence

  • Added onKnownStateChanged() hook; WritableStorage overrides it to debounce snapshot writes.
  • Snapshot persistence is best-effort and runs on state changes and close.
  • ReadOnlyStorage does not persist startup state (read-only remains non-mutating).

• Race hardening for lazy scans

  • Background scan callbacks guard against close-time races and rename/delete windows while reconciling filesystem state.

const storage = new Storage('storage', { dataDirectory, indexDirectory });

storage.open(); // restores known partitions/indexes from .storage.startup-state.json when available
// Full filesystem reconciliation continues lazily in background.

[coveralls]

coverage: 98.215% (-0.08%) from 98.299% — copilot/implement-persist-and-restore-state into main