[Pi] PiStorageBusyError on SQLite lock contention triggers fail-closed ctx.abort(), blocking interactive turns #601

What happened?

In @cortexkit/pi-magic-context (v0.44.4) on Windows 11, when concurrent background maintenance (such as session_project_backfill, dreamer smart-note sweeps, or LKG pruning) holds a write transaction on a large context.db (~2.6GB), any interactive turn that encounters SQLITE_BUSY (database is locked) fails closed instead of failing open:

[magic-context][pi] turn refused Magic Context storage is busy; send your message again
PiStorageBusyError: Magic Context storage is busy; send your message again
    at assertPiRawFallbackFits (D:/PiData/agent/npm/node_modules/@cortexkit/pi-magic-context/dist/index.js:28967:11)
    ...

The user is shown:
Magic Context could not safely prepare this turn; send your message again.
and ctx.abort() is called, immediately cancelling the user's interactive turn.

Reproduction & Log Evidence

1. Run Pi with @cortexkit/pi-magic-context on Windows 11 with an accumulated context.db over 1GB.
2. Background operations start holding transactions:

   [magic-context] slow write transaction: site=session_project_backfill held=3208.9ms
   [magic-context] slow write transaction: site=embedding_stale_gc held=1064.3ms
   [dreamer] compiled smart-note sweep failed: database is locked
   

3. A user message arrives during this lock window. In assertPiRawFallbackFits:

   if (!contextLimit || !Number.isFinite(contextLimit) || !observed || ...) {
     log("raw_fallback_refused completeness=partial");
     throw new PiStorageBusyError({ cause });
   }

4. The error propagates to registerPiGuardedContext:

   pi.on("context", async (event, ctx) => {
     try {
       return await handler(event, ctx);
     } catch (error) {
       log("[magic-context][pi] turn refused", error);
       if (typeof ctx.abort !== "function") throw error;
       try {
         pi.appendEntry(ENTRY_TYPE, { message: RETRY_MESSAGE });
       } finally {
         ctx.abort();
       }
       return { messages: event.messages };
     }
   });

5. ctx.abort() aborts the active Pi turn.

Expected Behavior

Unlike OpenCode where storage contention fails open (the pass continues or operations defer to the next natural cache bust), in Pi transient PiStorageBusyError should NOT abort the user's turn. It should either:

• Degrade gracefully / fail open to passing raw messages through unmodified ({ messages: event.messages }) without calling ctx.abort().
• Or retry with a brief exponential backoff before refusing.

Technical Analysis & Suggested Fix

1. In packages/pi-plugin/src/pi-context-refusal.ts:
   Check the error type in registerPiGuardedContext. If error instanceof PiStorageBusyError (or isTransientPiStorageError(error)), do not call ctx.abort(). Instead, log a warning and return { messages: event.messages } so the user is never blocked from interacting with the agent.
2. In packages/plugin/src/features/magic-context/storage-db.ts:
   Ensure background maintenance transactions (such as session_project_backfill) are batched into small slices (<100ms) rather than holding continuous multi-second locks on Windows.
3. Database Maintenance:
   Provide a command or automated retention prune to prevent context.db from growing into multi-gigabyte files that amplify lock contention on Windows.

Environment

• OS: Windows 11 (NTFS)
• Package: @cortexkit/pi-magic-context@0.44.4
• Harness: Pi 0.99.x
• Client: Pi