A live children query stops re-emitting after a create completes — missed Added on the change-feed → synced-query path #1053

Characterised while proving what #1040 was not. This is a distinct defect with no issue of its own until now.

The family

MeshNodeAgentFileStoreTest.*_StaysLive_AndReEmitsWhen* — at least:

• ListChildren_StaysLive_AndReEmitsWhenAFileAppears
• Search_StaysLive_AndReEmitsWhenMatchingContentAppears

Both have failed on main today.

The shape

A 30 s timeout where a live children query never re-emitted after a create completed. The create succeeds; the subscriber that should observe the new child never sees it. That points at a missed Added on the change-feed → synced-query path, not at the query itself.

What it is NOT — each ruled out with evidence, so nobody re-treads it

• Not cross-class shared state (AI.Test is not parallel-safe: cross-class shared state (repro in 100s via DOTNET_PROCESSOR_COUNT=4) #1040). It failed on main under serial execution, where no two classes run concurrently. AI.Test also turns out to have no cross-class shared state at all: ShareMeshClusterEnabled is false, so every [Fact] builds its own mesh.
• Not the deleted-address hang (An authoritative routing NotFound is produced but never becomes a verdict — the reader waits out its full budget #1029 / PR A deleted address must answer NotFound, not the transient ShuttingDown #1038). Those three tests contain no deletes at all. The A deleted address must answer NotFound, not the transient ShuttingDown #1038 mechanism requires a delete tombstone.
• Not the token-usage satellite ordering defect fixed in PR Fix the usage-satellite read and close #1029's second door (AI.Test parallel opt-in: measured no) #1043 — different tests, different mechanism (that one was a point-read of a satellite that may not exist yet).
• Not observed in the 14 runs of the Fix the usage-satellite read and close #1029's second door (AI.Test parallel opt-in: measured no) #1043 investigation, so it is intermittent and not provoked by parallelism.

Why it is worth its own issue

It is a liveness failure in the data-binding path, which is the mechanism every layout area and every Blazor view depends on. AGENTS.md is explicit that .Take(1) on a stream feeding a live view freezes the binding — this is the same class of symptom arriving by a different route, and if a change-feed Added can be missed, a user-facing view can silently stop updating.

Where to look

• The change-feed → synced-query hand-off: does an Added published between the initial snapshot and the live subscription have a drop window? A prior investigation established that StorageAdapterMeshQueryProvider subscribes persistence.Changes into an early backlog before the initial query and registers the live changeBuffer before initialDone = true, replaying through the same Concat — so that specific window is closed and the gap is elsewhere.
• Whether the create's write publishes IMeshChangeFeed.Updated on the path the children query is watching (an emit-on-start that does not publish is a documented failure mode here).
• PathMatcher.ShouldNotify / namespace-scoped change relevance for a children query specifically.

🚨 Do not fix by widening the 30 s timeout, adding a retry, or polling. The create completed; an event was owed and not delivered.