The SQLite session store's backup-and-reset recovery path in NewSQLiteSessionStore fired on any open or migration error, including transient ones. A canceled context (e.g. Ctrl-C during slow startup on a large DB) or SQLITE_BUSY/SQLITE_LOCKED from a second running docker-agent instance would silently rename a perfectly healthy session.db to session.db.bak and start fresh, causing users to lose access to all their old sessions. This was reproduced locally: a 708 MB database with 3342 sessions was moved aside by a single interrupted startup.

The fix introduces a sqliteutil.IsTransientError helper that matches canceled or expired contexts alongside SQLite primary result codes SQLITE_BUSY and SQLITE_LOCKED, including extended codes like SQLITE_BUSY_SNAPSHOT. The recovery path in pkg/session/store.go is now gated on this helper, so backup-and-reset only runs for genuinely corrupt or unrecoverable databases, never for errors that would resolve on retry.

Regression tests cover the new helper directly (TestIsTransientError, TestIsTransientError_SQLiteBusy) and the store behavior (TestNewSQLiteSessionStore_TransientErrorPreservesDB), verifying that a canceled context neither creates a .bak file nor discards existing session data.