Make strict startup content checks optional

docs/adr/2026_10_local_file_save_completion_and_batching.md

@@ -59,10 +59,12 @@ that evidence. The inspected Commonlib source is commit
 
 ## Decision
 
-Make local file processing recoverable until its result is established, use
-content and provenance to reconcile ambiguous timestamps, and enable batching
-in LiveSync mode only through an explicit choice after those contracts pass
-verification. Apply the recovery contract with batching enabled or disabled.
+Make local file processing recoverable until its result is established, retain
+strict content and provenance reconciliation for manual and recovery scans, and
+enable batching in LiveSync mode only through an explicit choice after those
+contracts pass verification. Ordinary Obsidian start-up may skip a body read
+only under the exact-match conditions below. Apply the recovery contract with
+batching enabled or disabled.
 
 The content-reconciliation change targets selected ordinary files in the
 Offline Scanner's `NEWER_WINS` / `sync-newer` action. Keep the existing action
@@ -208,12 +210,14 @@ finishes; correctness must also follow from the persistent record and start-up
 reconciliation. Remote availability must not determine whether local pending
 work survives shutdown.
 
-### 4. Reconcile content when timestamps are inconclusive
+### 4. Preserve strict content reconciliation
 
-Retain the existing timestamp tolerance for platforms with coarse modification
-times. Timestamp equality, including exactly equal raw timestamps, does not
-prove content equality. The Offline Scanner must establish one of the following
-outcomes through the ordinary non-forced file handler and its provenance rules:
+Strict content checking retains the timestamp and provenance reconciliation
+contract for platforms with coarse modification times. Timestamp equality,
+including exactly equal raw timestamps, does not prove content equality. With
+strict checking enabled, the Offline Scanner must establish one of the
+following outcomes through the ordinary non-forced file handler and its
+provenance rules:
 
 | Evidence                                                                                                                | Required outcome                                                                                                                  |
 | ----------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
@@ -223,7 +227,19 @@ outcomes through the ordinary non-forced file handler and its provenance rules:
 | Vault content has no provable origin and matches no current live leaf                                                   | Preserve it according to the existing independent-branch rules. Do not attach it to an arbitrary database winner.                 |
 | Required content or provenance cannot be read, or state changes during comparison                                       | Retain unresolved work and report or re-evaluate it. Do not mark it reconciled merely because the timestamp comparison is `EVEN`. |
 
-The table describes stable-state reconciliation, not atomic database and
+The `strictContentCheck` scan option is strict when omitted. Ordinary Obsidian
+start-up can opt out through **Strict content check on startup**, which is
+disabled by default. With the option disabled, a body read may be skipped only
+when the file's raw modification time, byte size, and valid device-local
+provenance exactly match a conflict-free current revision and no file
+processing is pending. All other files retain strict content reconciliation.
+An unrecorded edit that preserves its exact size and modification time can
+therefore remain undetected by ordinary start-up while the option is disabled.
+Manual scans, Fetch, Rebuild, and other explicit recovery operations remain
+strict. Pending-event replay, incoming-change protection, and deletion guards
+remain active in both modes.
+
+The table describes stable-state strict reconciliation, not atomic database and
 provenance persistence. Replay in the pre-provenance gap may create an
 identical sibling; with no remote descendant, one of the identical branches
 is tombstoned, leaving one live leaf with the exact saved content. If replication has
@@ -249,12 +265,14 @@ Obsidian start-up can report `completed-with-file-failures` and allow unaffected
 files to proceed; an unresolved pair must not become `completed` to achieve
 that result. Keep the stricter callers' existing completion requirements.
 
-This deliberately extends the current equal-time scanner contract. Existing
-provenance tests expect no database write during that scan, including for an
-edited file. Preserve their unchanged-file and later incoming-protection
-scenarios; change the edited-file expectation to require preservation during
-the scan itself. Test both identical timestamps and distinct raw timestamps
-within one comparison bucket.
+Keep the original unchanged-file, edited-file, untracked-provenance,
+incoming-protection, and concurrent-recheck fixtures under strict content
+checking, including identical timestamps and distinct raw timestamps within
+one comparison bucket. Do not weaken those strict-mode assertions to describe
+the ordinary start-up opt-out. Test the opt-out separately: only the exact
+stat, provenance, conflict-free, and no-pending-processing match may skip a
+body read. Pending-event replay and incoming or deletion guards remain covered
+with the opt-out enabled.
 
 ### 5. Make batch timing and activation explicit
 
@@ -369,7 +387,9 @@ matrix is:
 | Handler returns false, throws, or snapshot persistence fails                                                         | Flush reports failure; pending work is retained; unrelated recoverable work can continue.                                              |
 | Buffered or in-progress work exists with no waiting timer                                                            | Flush still waits for actual completion.                                                                                               |
 | A flush overlaps new typing or a rename/delete barrier                                                               | The captured work completes without waiting for later work or deadlocking.                                                             |
-| Equal timestamps: unchanged, edited, untracked, pruned provenance, unavailable Chunks, or concurrent recheck changes | Preserve correct ancestry and bytes, avoid duplicate revisions, and distinguish unresolved comparisons from successful reconciliation. |
+| Strict check: equal timestamps, unchanged or edited files, untracked or pruned provenance, unavailable Chunks, or concurrent recheck changes | Preserve correct ancestry and bytes, avoid duplicate revisions, and distinguish unresolved comparisons from successful reconciliation. |
+| Start-up check disabled: exact raw time, size, and provenance match with no conflict or pending processing | The body read may be skipped; an unrecorded edit which preserves exact size and modification time remains an accepted limitation. |
+| Pending-event replay and incoming or deletion guards, with either start-up setting | Keep replay and protection active; do not skip work or remove a file based only on matching statistics. |
 | Settings save followed by stop; ordinary unload; interruption during replay                                          | No operation is forgotten because a settings callback or shutdown released its timer.                                                  |
 | Sustained edits and more paths than available processing slots                                                       | Observe the intentional-delay deadline and progress of unrelated ready files.                                                          |
 | Old settings, mode changes, explicit opt-in, and settings import                                                     | Existing LiveSync mode users retain immediate saving until they choose batching.                                                       |

docs/settings.md

@@ -989,6 +989,12 @@ If enabled, chunks will be split into no more than 100 items. However, dedupe is
 Setting key: useSegmenter
 If this enabled, chunks will be split into semantically meaningful segments. Not all platforms support this feature.
 
+#### Strict content check on startup
+
+Setting key: strictContentCheckOnStartup
+
+When enabled, ordinary start-up compares file content with the local database even when the file's exact modification time and size match. When disabled (the default), this comparison can be skipped only when the modification time, size, and recorded device-local provenance match a conflict-free current revision, and no file processing is pending. An edit made outside the normal file-event path which preserves its exact modification time and size can therefore go undetected by ordinary start-up. Manual scans and explicit Fetch or Rebuild operations keep strict content checking.
+
 ### 3. Transfer Tweak
 
 #### Fetch chunks on demand