Hazard review

• scenarioreviewedboundaryedge_case

  Worst case: a merge that mutates its input maps mid-render corrupts the live item set the view is drawing from (lost rows, duplicated entries compounding across runs) - the purity half of the contract closes it: both functions build fresh containers and only read their inputs. boundary: the zero cases are pinned - empty/missing maps and arrays normalize to fresh empties, an orphan id (order entry with no item) is dropped rather than carried, and a duplicated incoming id is listed once, first occurrence winning. edge_case: incoming row objects do get order (and providerMenu on the swap path) written onto themselves - the never-write half covers the input maps as the contract states, and call sites pass provider-fresh rows; a static item claiming another provider providerMenu is dropped when that provider reruns (config-owned data at the same authority), provider rows claiming static ids are skipped so static beats provider, and app rows are always replaced wholesale by mergeAppRows.

• propertyrevieweddeterminismtotality

  determinism: both merges walk the given order then the given rows with a first-wins id policy, so identical inputs produce identical (items, itemOrder) pairs every run. totality: every (source, order, incoming) shape resolves to a defined fresh pair - orphan, duplicate, replaced-provider, and static-claim ids each have exactly one disposition, and no input combination falls through undefined.

• structuralnot applicable

  Plain object/array construction with no aliasing of source containers into the result (entries are shared by reference intentionally - value records by convention); no eval, encoding, or pointer surface.

• domainnot applicable

  In-memory map merges over user-owned menu data; no trust boundary is crossed and the traced functions carry no network, crypto, privilege, or wait surface.