meta overlay: a just-saved overlay is listed but not dispatchable for a short window — a cache between saveMeta and resolveRouteActionDeclaration lags the write #4521

Split out of #4432 so it is not buried when that issue closes. Unassigned — nobody is on this.

#4432's repro (v17 verification, F1) reported two distinct defects. The type-segment namespace split is fixed in #4520. This is the other one, which #4520 deliberately did not touch (Prime Directive #10 — no silent scope expansion).

Observed

Quoting the original report (step 2 aftermath):

after step 2 the overlay was listed but not dispatchable for a short window (POST answered the ADR-0110 "has no declaration" 404, then succeeded on a later call) — some cache between saveMeta and resolveRouteActionDeclaration lags the write.

So immediately after a successful PUT /api/v1/meta/action/<name>:

• GET /api/v1/meta/action already lists the item, but
• POST /api/v1/actions/<object>/<name> answers the ADR-0110 404 … has no declaration,
• and a later identical POST succeeds.

Why it is worth its own issue

Two read surfaces disagree about the same write for a bounded but nonzero window, and the disagreement is timing-dependent, so it reads as a flake to anyone who hits it. It is also the shape a Studio "save then run" flow walks straight into.

saveMetaItem already awaits its projection before the fire-and-forget listeners (ADR-0094) and emits emitMetadataMutation synchronously; the lag is presumably downstream of that, in whatever resolveRouteActionDeclaration reads. Worth determining whether the dispatch resolver caches per-process without subscribing to the mutation event, or subscribes but is invalidated asynchronously — the fix differs.

Not reproduced here

I did not reproduce this myself; I am recording it so the observation survives #4432 closing. Original evidence: #4432, "Also observed" paragraph. Environment there: showcase under os serve --dev, admin session, main @ 1ee48bc60.

Part of the #3909 rc.1 verification (section F1) family.