Hazard review

• scenarioreviewedmalformed_input

  Worst case graded above (in-place swap loss compounding into duplicate rows - the shipped-history defect, fixed by mergeMenuSources/mergeAppRows/swapProviderRows rebuilding fresh objects and never writing into QML var properties). malformed_input: a junk provider row (missing id, non-object) or a duplicate desktop id is skipped at the guard, so junk never enters the map, and ids already claimed are listed once by the nextItems occupancy check. Orphaned ids (provider vanished its batch) are dropped rather than carried, so a lost write cannot compound. Static JSONC rows are untouched by the swap, per contract.

• propertyreviewedatomicityidempotency

  atomicity: each swap assigns fresh items/itemOrder objects to the model in one go - a reader observes either the old batch or the new one, never a half-swapped map; the atomicity obligation is graded above. idempotency: rerunning a provider with the same rows converges on the same map (rows replaced by providerMenu tag, order recomputed), so rescan loops stabilize. determinism: same inputs yield the same row order (arrival order, stable).

• structuralnot applicable

  JS map/array rebuild under a GCd engine: no manual memory, pointer, or encoding surface; the dropped-write mechanism is an engine quirk dispositioned under property.atomicity (fresh-object assignment), not a structural class. Depth/path walks carry 32-deep guards (MenuModel depthFor/pathFor), so a cyclic parent chain cannot loop.

• domainnot applicable

  the swap contract is in-process QML/JS state; provider enumeration runs are external calls but their deadlines belong to the provider requirements (children Z680/EFNR reviewed in batch B), not to the swap semantics this req carries. No trust boundary: provider rows and desktop ids originate on the same machine under the user account; concurrency classes do not fire (single-threaded event loop, swap is one synchronous function).