Treat three timing-dependent island ordering programs as races

g01 (twenty fs.stat round trips against a 2 ms timer), p10 (two 0 ms
timers armed on either side of an island call) and s06 (fs callbacks and
timers pending when Node loads) each failed one CI run in a different
lane: their order depends on how long the island call or the I/O takes,
which differs between the sides and grows under ASan. Their native runs
now have to produce the lines of one of Node's outputs, like the other
race programs.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

tests/corpus-node-islands-order/g01-fs-chain/main.ts

@@ -1,4 +1,5 @@
 // @requires-libnode
+// @order: race
 // X { T 0 { F 20 { L i-fs-chain } } } T 2 { B 80 L h-sync }
 import { callSync } from "@scriptc/node";
 import { readFile, writeSync } from "node:fs";

tests/corpus-node-islands-order/p10-island-chain/main.ts

@@ -1,4 +1,5 @@
 // @requires-libnode
+// @order: race
 // X { T 0 { L i-a K { L i-tick } M { L i-micro } I { L i-imm } } } T 0 { L h-t0 M { L h-micro } }
 import { callSync } from "@scriptc/node";
 import { readFile, writeSync } from "node:fs";

tests/corpus-node-islands-order/s06-load-with-pending-fs-and-unref/main.ts

@@ -1,4 +1,5 @@
 // @requires-libnode
+// @order: race
 // Switch: fs callbacks and an unref'd timer are pending when Node loads; the
 // unref'd timer must not keep the program alive, the refreshed one must.
 import { callSync } from "@scriptc/node";

tests/harness/node-island-order.test.ts

@@ -13,8 +13,11 @@
  * A program whose head says `// @order: race` races a timer against I/O
  * whose duration differs between the sides (scriptc's own fs callbacks
  * complete in one turn where Node's readFile takes several; module loading
- * on the first call into Node takes longer than in a Node process), so
- * Node permits orders it rarely produces in M runs. Its native runs must
+ * on the first call into Node takes longer than in a Node process), or two
+ * equal timers armed on either side of an island call, which a millisecond
+ * boundary between them (likely in a sanitized build) puts in different
+ * loop turns, so Node permits orders it rarely produces in M runs. Its
+ * native runs must
  * produce the lines of one of Node's outputs, in any order; the report
  * still records whether the order itself was among Node's.
  *