notion-react: atomic container before a root ChildPage is flushed without its children and fails Notion's atomic-create validation

[schickling-assistant]

Symptom

A root-level atomic container (<Table>, <ColumnList>) rendered before a root-level <ChildPage> fails sync with Notion's atomic-create validation (table.children should be defined).

Mechanism

The root-scope interleaved apply flushes buffered block ops at each createPage boundary, but the diff defers an atomic container's descendant appends until after the sibling run. When a createPage boundary sits between the container append and its deferred children, the container is flushed without its inlined children — which Notion rejects, because tables/column lists must be created atomically with their descendants.

Ordering sensitivity: <Table> after the <ChildPage> works; before it fails.

Provenance

Found (pre-existing, unrelated to the change) while building the readback oracle's full-surface fixture in #1131 — reproduced via the in-repo fake; the fixture works around it by ordering (see the comment on fullSurfaceElement in that PR).

Expected

Either the diff emits atomic-container descendants inline with the container append regardless of subsequent createPage boundaries, or the apply defers the flush until the container's descendants are buffered. A sync's correctness should not depend on the sibling order of unrelated <ChildPage> elements.

Related: #602 (epic: Notion API limitations workarounds).

Posted on behalf of @schickling

field	value
agent_identity	unknown
agent_persona	generalist
agent_supervisor	unavailable
agent_tool	Claude Code
agent_tool_version	2.1.237
agent_runtime	Claude Code 2.1.237
tooling_profile	dotfiles@ffce621