storage: clarify auto-snapshot interval contract — start-to-start vs completion-to-start

[qnbs]

Context

Found during PR #609's review reconciliation (a CodeAnt AI top-level nitpick, not a resolvable inline thread). Verified against main@3f9d0a7e — this exact semantic predates #609 and is unrelated to that PR's WCAG/appearance-default scope.

Current behavior

services/storage/idbProjectStore.ts's saveProject():

const snapshotTime = Date.now();
this.createSnapshot(projectData)
  .then(() => {
    this.lastAutoSnapshotTime = snapshotTime;
    return this.pruneAutoSnapshots();
  });

lastAutoSnapshotTime is set to the timestamp captured before createSnapshot() starts, not when it completes. The next auto-snapshot is gated by Date.now() - this.lastAutoSnapshotTime > this.AUTO_SNAPSHOT_INTERVAL (5 minutes).

Two possible contracts

• A. "At most one snapshot start per 5 minutes" — current code is correct as-is; the gate should measure from the previous start.
• B. "Wait ≥5 minutes after a snapshot completes before starting the next" — current code under-waits by the snapshot's own duration; a very slow snapshot (≥5 min) could allow the next one to start immediately after completion.

Why this isn't a simple bug

This isn't an oversight: PR #517 explicitly reviewed this exact area (introducing the autoSnapshotInFlight guard against concurrent snapshot starts) and its own review thread states the "delayed-timestamp-on-success" behavior was already deliberate and was preserved on purpose, not defaulted into.

Impact if contract B is intended

Under sustained slow snapshots (large projects / slow storage), automatic snapshots could fire closer together than 5 minutes apart, worst case immediately back-to-back after a snapshot that itself took ≥5 minutes. autoSnapshotInFlight still prevents true concurrent duplicates, so this is a scheduling-cadence issue, not a data-loss or correctness issue.

Ask

Decide which contract (A or B) is actually intended, and if B, move the lastAutoSnapshotTime assignment to capture Date.now() inside the .then() rather than before the call. Low severity, no urgency.

[qnbs]

Product/recovery exploration for this topic now also lives in Discussion #641: #641. This Issue remains the implementation/acceptance tracker; the Discussion does not change priority, roadmap admission, acceptance criteria, or execution sequencing by itself.