fix(recovery): support batched SQLite blob writes

README.md

@@ -165,11 +165,16 @@ the original archive and stores only the selected members. Password-protected
 ZIP passwords remain request-only and are never included in the preview token.
 
 Managed blob writes and applied orphan cleanup use Core's durable recovery
-ledger. Intent, request digests, recovery mode, and a distributed lease are
-committed before physical storage effects; the Files session commit verifies
-database and streamed object evidence, while rollback compensates only a newly
-reserved unreferenced key. New object keys are opaque and do not retain the
-uploaded filename. Uncertain or mismatched effects remain visible through Ops.
+ledger. On PostgreSQL, intent, request digests, recovery mode, and a distributed
+lease are committed before physical storage effects; the Files session commit
+verifies database and streamed object evidence, while rollback compensates only
+a newly reserved unreferenced key. Development SQLite records blob intent in
+the caller transaction to avoid its second-writer deadlock, then verifies on
+commit or reconstructs compensation evidence after handled rollback. Because a
+hard loss before that commit can leave an unrecorded object, SQLite requires a
+complete integrity scan after a crash and is not a production recovery profile.
+New object keys are opaque and do not retain the uploaded filename. Uncertain
+or mismatched effects remain visible through Ops.
 
 Operators with `files:file:admin` can run bounded, resumable integrity scans in
 Administration. Scan batches and finding actions carry monotonic revisions;