gc test: large_object_old_born_array_slot_write_keeps_young_child_alive asserts an exact whole-nursery copied_objects count and fails on macOS (4249 vs 1) — pre-existing on main #7060

Not introduced by anything in flight — verified against a pristine build of origin/main @ e279b2d54 before filing.

Reproduce

cargo build --release -p perry -p perry-runtime -p perry-stdlib \
  -p perry-runtime-static -p perry-stdlib-static
cargo test --release -p perry-runtime --lib -- \
  --exact gc::tests::copying::large_object_old_born_array_slot_write_keeps_young_child_alive

thread '…large_object_old_born_array_slot_write_keeps_young_child_alive' panicked at
crates/perry-runtime/src/gc/tests/copying.rs:1313:5:
assertion `left == right` failed
  left: 4249
 right: 1
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 1524 filtered out

Line 1313 is

assert_eq!(trace.copying_nursery.copied_objects, 1);

The test builds one large old-born array with a single young child, writes the child into slot 0, and asserts the copying minor relocates exactly that one young object. It relocates 4 249.

It is the environment, not the change under test

I hit it while validating #7024 and did the control before concluding anything: the failure is byte-identical on the pristine e279b2d54 tree (same panic site, same left: 4249), so it is not caused by the deferral change. It also reproduces with --exact in a fresh process, so it is not cross-test state either — 4 249 live young objects are simply present in the nursery at the point the test forces its minor.

That points at runtime startup allocations differing between this host and the CI runner. cargo-test on main is red for an unrelated reason (direct_eval_non_definable_global_var_throws, a crates/perry/tests case), and this test is not among the reported failures there, so it evidently passes on ubuntu-latest.

Why it matters

The assertion is an exact equality against a whole-process quantity. Whatever makes 4 249 young objects live at that point on macOS will make the number different again on the next platform or the next startup change, and the test says nothing about the property it is trying to pin — that the old-to-young edge kept this child alive and rewrote this slot, which the surrounding assertions already check.

Two candidate fixes, in preference order:

1. Assert the child specifically: the test already computes rewritten and asserts it is a nursery pointer distinct from child. Add that the child's forwarded copy is among the copied set, and drop the exact count — or assert copied_objects >= 1.
2. Give the test a controlled nursery (the CopyingNurseryTestGuard it already uses) that starts from a known-empty young generation, so the exact count is meaningful.

Environment: macOS 15 (Darwin 25.5.0), arm64, release profile, cargo test --release -p perry-runtime --lib.

Related: #6981, #7019.