[kryptobaseddev]

Why

review-2253 blocked #2338's ordering, where the projection commits before docs-update writes its row. Lead chose option (a): compute the merged text without committing, write the blob and row from it, then commit the projection. This PR adds the read-only entry point that #2338 stacks on.

What

previewDocUpdateThroughSections(projectRoot, input: ProjectDocUpdateInput): Promise<DocUpdatePreview> in packages/core/src/docs/section-write-path.ts, returning { mergedText, wouldAdvance, conflicts }.

• It runs the exact projection (merge, adopt, version append, head upsert) inside the same BEGIN IMMEDIATE transaction, then rolls it back via an internal PreviewRollback. So wouldAdvance is the real head.advanced, not an estimate.
• It acquires no leases.
• The version uids in conflicts name rolled-back rows, so callers should use only sectionId.
• A content-addressed blob may remain as a harmless orphan.
• projectDocUpdateThroughSections is unchanged; both functions share a private projectDocUpdate(…, preview).

Evidence

• New test in section-write-path.test.ts, "T13842: previewDocUpdateThroughSections returns the merged text the projection lands, and writes nothing". It covers a stale-base append merge: the preview's merged text equals what the real projection then lands, and the version count, head uid, section state and leases are all unchanged after the preview.
• Local runs before the owner's no-local-heavy-runs directive: section-write-path.test.ts 30/30 on current main, core tsc --noEmit with 0 errors, and gate 38 --base origin/main OK. Biome is clean on both files. GitHub CI is the authoritative evidence.

🤖 Generated with Claude Code