fix: make collection document node order deterministic

[ehennestad]

Found by the R2022a leg of CI failing FixtureTest/testSerializedOutputMatchesGoldenFixture on every PR in this stack, while the R2026a leg passed.

The defect

The nodes of a collection document appeared in whatever order Collection returned them, and that order depends on the MATLAB release. Collection stores its nodes in a dictionary from R2022b, which preserves insertion order, and in a containers.Map on older releases, which returns values sorted by key. The same collection therefore serialized to a different document on R2022a than on R2022b and later — the CI log showed the nodes alphabetical by @id on R2022a, while the golden fixture, generated on R2025b, held them in insertion order.

A @graph is semantically an unordered set, so no conforming reader is affected. But a document that differs by release cannot be compared against a golden file, defeats reproducible output for anyone keeping their metadata under version control, and produces noisy diffs when the same collection is saved from two machines.

The fix

The nodes of a collection document are sorted by @id before the document is assembled, in JsonLdSerializer.createCollectionDocument. Both container types then produce byte-identical documents, and the golden fixture comparison in the PR above this one is release-independent.

Documents emitted separately, one per instance, are deliberately not reordered: FolderMetadataStore pairs serialized documents with their instances by position, so reordering them would write each document to the wrong file.

Regenerating the golden fixture under this ordering (done in the PR above) reproduced byte-for-byte the order R2022a emitted in CI, which confirms the diagnosis.

Why it sits at the bottom of the stack

The golden fixture is introduced by the tests PR directly above, and its comparison only holds across releases once the order is deterministic. Every PR in the stack inherits the fix, so all CI legs can go green from the bottom up.

An alternative was to make the fixture comparison order-insensitive and leave the output nondeterministic. That would hide the release dependence rather than remove it, and would weaken the byte-for-byte comparison that caught two shape regressions while the serializer was being reworked later in this stack.

🤖 Generated with Claude Code

[github-actions]

Test Results (R2022a)

700 tests   700 ✅  2m 24s ⏱️
 17 suites    0 💤
  1 files      0 ❌

Results for commit c88ae83.

♻️ This comment has been updated with latest results.

[github-actions]

Test Results (R2026a)

700 tests   700 ✅  2m 17s ⏱️
 17 suites    0 💤
  1 files      0 ❌

Results for commit c88ae83.

♻️ This comment has been updated with latest results.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 77.11%. Comparing base (8a8961a) to head (c88ae83).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #113      +/-   ##
==========================================
+ Coverage   77.07%   77.11%   +0.03%     
==========================================
  Files         417      417              
  Lines        4022     4028       +6     
==========================================
+ Hits         3100     3106       +6     
  Misses        922      922              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.