accounts_free_is_linear_in_its_blocks failed once on macOS ASan (22x for 4x the blocks) #3488

accounts_free_is_linear_in_its_blocks (tests/runtime/test_exec_accounts.c:260) failed on PR #3477's macOS AddressSanitizer & LeakSanitizer leg (run 41141005452, the UBSAN test step). The PR does not touch the runtime's accounts.

account_free: 10000 blocks 0.23 ms, 40000 blocks 5.13 ms
ASSERT_TRUE failed at tests/runtime/test_exec_accounts.c:265: large < small * 8.0 || large < 2.0

Four times the blocks took 22 times as long, and the time was past the 2 ms floor. The test takes the best of three runs of each size, but under the sanitizers on a shared macOS runner a single slow interval can still decide it. Main has passed this workflow on its last 8 runs.

Two causes to tell apart:

• runner noise: then the bound should not rest on one short interval, for example by timing more blocks, or comparing per-block cost over several sizes;
• a real superlinear step under ASan (the one-pass free with its address filter, runtime: the execution accounts' table lock: account_free is quadratic under it, and every allocation takes it while any account exists #3410): then the free is worth measuring under ASan locally.

For the next batch; the failed job was re-run on #3477.