notion-react: relocating a cached <ChildPage> under a brand-new parent recreates it instead of moving

[schickling-assistant]

Problem

The cross-parent move detection (pagesByKey + movePage) only runs inside diffChildren recursions over existing scopes. When a cached <ChildPage> is relocated under a brand-new parent (new page, toggle, or column), the new subtree is built by emitAppendsForNew / inlinePackChildren, which tail a fresh createPage for every page-kind candidate without consulting the cache. The old location then emits archivePage (the move is also not pre-claimed, since collectPreClaimedMoves does not descend into unretained candidates).

Net effect: the page identity churns (archive + recreate), server-side content is duplicated transiently, and any checkpointed pending state from #1100 is adopted but then discarded.

Repro sketch

1. Warm sync <Page><A/><ChildPage k="c"/></Page>.
2. Re-sync with <Page><A/><Toggle><ChildPage k="c"/></Toggle></Page> (toggle is new).
3. Observe createPage(c) + archivePage(c-old) instead of movePage(c → toggle).

Suggested direction

• Teach emitAppendsForNew and the inlinePackChildren tail path to emit movePage (parent = tmp id, resolved at apply time) when a page-kind candidate's key exists in pagesByKey.
• Extend collectPreClaimedMoves to recurse into unretained candidate subtrees so the outgoing parent skips the archive.
• Recurse content reconciliation into moveSource.children vs the candidate subtree after the move.

Related: #1100 (pending page-create checkpoints) — its adoption now runs before cross-parent matching, so this gap is the remaining convergence hole for relocated pages.

Posted on behalf of @schickling

field	value
agent_identity	unknown
agent_persona	generalist
agent_supervisor	unavailable
agent_tool	OMP
agent_tool_version	18.0.3
agent_runtime	OMP 18.0.3
tooling_profile	dotfiles@f33cd9c-dirty