fix: adopt Commonlib 0.4.1 recovery fixes

docs/adr/2026_11_local_file_operation_retry.md

@@ -9,10 +9,14 @@ status: accepted
 
 ## Status
 
-Accepted on 2026-11-08. Implemented in Commonlib and locally verified through
+Accepted on 2026-11-08. Implemented in Commonlib and initially verified through
-an exact packed candidate. Package publication and the final Self-hosted
+an exact packed candidate. The version fields retain the original reviewed
-LiveSync dependency update are pending. The version fields identify the
+baseline.
-reviewed baseline; this behaviour remains unreleased.
+
+Publication note (9th November, 2026): The implementation is published in
+[Commonlib 0.4.1](https://github.com/vrtmrz/livesync-commonlib/releases/tag/0.4.1).
+Self-hosted LiveSync now pins that exact registry version in its root dependency.
+Publication in a Self-hosted LiveSync release remains pending.
 
 This decision extends [local file save completion and batching](2026_10_local_file_save_completion_and_batching.md)
 with finite retries during the same application session. Its durable completion,
@@ -306,6 +310,12 @@ repair. The complete Commonlib and consumer checks, including the three real
 Obsidian scenarios, passed with the extracted implementation. Final TSDoc-only
 corrections preserve the tested package's runtime bytes and declaration syntax.
 
+Registry-package verification on 2026-11-09 passed clean installation with npm
+10 and npm 11, the complete consumer checks and unit tests, WebApp and WebPeer
+builds, and all 19 CLI E2E tasks under Node.js 26. The published Commonlib 0.4.1
+files matched the installed package. The 12 focused database-text assertion cases
+and all three real Obsidian scenarios also passed with that registry installation.
+
 The [real Obsidian scenario](../../test/e2e-obsidian/scripts/local-file-retry.ts)
 uses ordinary Vault events and targeted read failures. It verifies a failed
 temporary read followed by rename recovery, a retained same-path successor

package-lock.json

@@ -23,7 +23,7 @@
                 "@smithy/types": "^4.14.3",
                 "@smithy/util-retry": "^4.4.5",
                 "@vrtmrz/browser-ui-kit": "0.1.0",
-                "@vrtmrz/livesync-commonlib": "0.4.0",
+                "@vrtmrz/livesync-commonlib": "0.4.1",
                 "@vrtmrz/obsidian-plugin-kit": "0.1.7",
                 "@vrtmrz/ui-interactions": "0.1.2",
                 "@vrtmrz/value-store": "0.1.0",
@@ -4081,9 +4081,9 @@
             }
         },
         "node_modules/@vrtmrz/livesync-commonlib": {
-            "version": "0.4.0",
+            "version": "0.4.1",
-            "resolved": "https://registry.npmjs.org/@vrtmrz/livesync-commonlib/-/livesync-commonlib-0.4.0.tgz",
+            "resolved": "https://registry.npmjs.org/@vrtmrz/livesync-commonlib/-/livesync-commonlib-0.4.1.tgz",
-            "integrity": "sha512-2bhkrd0rRWSiy90rjOxpaO01Ei2V9VSwifzv4ePUttxrzt195zjWNZCzW9ZMvJvAtyPoifShilW0J4kig4oKFA==",
+            "integrity": "sha512-lp0RLvFIIO2qJbWqxFMGhPZpe3SjydfhJLQkEtou8Db7ls7H9Op9fYIhRA08lr6CRWymZ5HbqHf2xdDmE3YB3g==",
             "license": "MIT",
             "dependencies": {
                 "@aws-crypto/sha256-js": "5.2.0",

package.json

@@ -212,7 +212,7 @@
         "@smithy/types": "^4.14.3",
         "@smithy/util-retry": "^4.4.5",
         "@vrtmrz/browser-ui-kit": "0.1.0",
-        "@vrtmrz/livesync-commonlib": "0.4.0",
+        "@vrtmrz/livesync-commonlib": "0.4.1",
         "@vrtmrz/obsidian-plugin-kit": "0.1.7",
         "@vrtmrz/ui-interactions": "0.1.2",
         "@vrtmrz/value-store": "0.1.0",

test/e2e-obsidian/README.md

@@ -112,7 +112,7 @@ The same scenario checks the five actions in Reporting Tools, the separate Check
 
 `third-party-chunks` reflects synthetic externally generated text through the installed Commonlib and the real Obsidian file handler. It supplies a split surrogate pair at the file-access read boundary, with size checking enabled, then verifies exact Vault and on-disk text, unchanged Metadata, and matching persisted provenance. Complete-pair text and a binary attachment provide controls. The underlying Metadata and Chunks are real local database entries; this does not establish that CouchDB or a particular third-party application generates this chunk layout. No remote service is required.
 
-`local-file-retry` verifies the [local retry contract](../../docs/adr/2026_11_local_file_operation_retry.md). Until the corresponding Commonlib package is published and adopted, it requires the packed candidate; the reviewed Commonlib 0.4.0 package is its failing baseline. It needs no remote service. It injects a targeted `ENOENT` from `app.vault.adapter.read`, then uses real Vault create, rename, and modify events to check local retry after a rename, a later same-path edit, and a natural restart. Assertions require plain Metadata and content datatypes with the exact expected database text, as well as exact Vault bytes, pending events, and revision ancestry. The same-path edit is observed without a manual flush; the restart reuses the same isolated Vault and profile and checks the combined start-up recovery result. It does not isolate snapshot replay from the normal Vault scan; Commonlib's dedicated replay tests cover that mechanism.
+`local-file-retry` verifies the [local retry contract](../../docs/adr/2026_11_local_file_operation_retry.md). It uses the pinned, published Commonlib 0.4.1 package; Commonlib 0.4.0 remains the original failing regression baseline. It needs no remote service. It injects a targeted `ENOENT` from `app.vault.adapter.read`, then uses real Vault create, rename, and modify events to check local retry after a rename, a later same-path edit, and a natural restart. Assertions require plain Metadata and content datatypes with the exact expected database text, as well as exact Vault bytes, pending events, and revision ancestry. The same-path edit is observed without a manual flush; the restart reuses the same isolated Vault and profile and checks the combined start-up recovery result. It does not isolate snapshot replay from the normal Vault scan; Commonlib's dedicated replay tests cover that mechanism.
 
 `stale-file-restart` needs no remote service. It advances the local database while old Vault bytes remain, persists pending storage events, and restarts the same isolated Vault and profile. It checks that an unchanged file whose recorded revision has been pruned receives the newer database content using persisted content evidence without creating a revision, that unknown-origin content is preserved on a fresh independent branch, and that losing provenance and processing the file again does not duplicate or automatically merge that branch. A third file begins with no provenance while its bytes still match the current database revision; start-up must record that revision without creating a new one, and a later incoming revision must reflect without a conflict. A fourth file has legacy revision-only provenance; start-up must verify its exact content and add a hash without creating a database revision or changing storage. The database advances and pending snapshot are controlled fixtures; start-up processing, persistence, file reflection, and conflict checking run in real Obsidian. The scenario does not simulate a mobile operating system suspending the application.
 

updates.md

@@ -12,6 +12,14 @@ Earlier releases remain available in the 1.0 release history, the 1.0 preview hi
 
 ## Unreleased
 
+### Fixed
+
+#### Synchronisation and recovery
+
+- A transient failure while reading an ordinary Vault file no longer blocks synchronisation until Obsidian restarts. A later related file change or **Apply pending changes now** can retry the pending work using the current Vault state. (#1331)
+
+- Existing Vault files can be reconciled after CouchDB Fetch when on-demand replication omitted their Chunks. Strict content comparisons can retrieve the missing Chunks through the existing settings, including when Fast Setup falls back to Standard Fetch. (#1329, #1332)
+
 ### CLI
 
 #### Fixed