#3043 Flaky test: ModelResolver data accessors for a renamed model return the earlier id's record from findBySpec

Description

The test ModelResolver.buildContext: data accessors treat a renamed model's data like data under an earlier id of its new name in src/domain/expressions/model_resolver_test.ts fails intermittently. It was added by swamp-club#3029 (PR #2838).

It failed the run-tests step of a verify-build run for an unrelated branch (swamp-club#2905, rebased onto main at cd2183ee), which does not touch this file or the code under test.

Steps to reproduce

On a checkout that includes #2838:

deno run test src/domain/expressions/model_resolver_test.ts

Run it several times. On the swamp-club#2905 branch it failed in 5 of 7 runs of the file alone; a full-suite run on the same tree passed. It was not run on a clean main checkout. Sometimes the buildLightContext variant fails as well (2 failures in one run).

Actual

error: AssertionError: Values are not equal.
    [
-     "c52b6258-bece-46d8-94fd-b3402fd45812",
+     "ebc8cd00-c4f3-4a30-bdd8-426f3519e323",
    ]
    at model_resolver_test.ts:2994

ctx.data.findBySpec("new-name", "result") returns the record written under the earlier model id, where the test expects the current model id (the one renamed from tmp-name). The preceding listVersions assertion passes.

Expected

The test passes on every run, or, if the accessor's choice between the two ids depends on something the test does not control (for example write timestamps that land in the same millisecond), that is fixed in the accessor or pinned in the test.

Notes

Not diagnosed. The three writes in the test happen back to back, so an ordering tie between the two model ids is one possibility; a real ordering bug in the #3029 change is another.