Codegen emits external global declarations in nondeterministic order (IR differs run to run) #11409

Compiling the same source twice with the same perry binary can produce different LLVM IR. The difference is ordering: two external global declarations swap places. This weakens the object cache's "only the IR bytes decide the object" contract (#7131) and makes byte-level IR comparisons unreliable.

Reproduce (seen with a perry-dev build of main as of 2026-09-26):

export PERRY_NO_CACHE=1 PERRY_NO_AUTO_OPTIMIZE=1
for i in 1 2; do mkdir -p ll$i; PERRY_SAVE_LL=$PWD/ll$i perry compile test-files/test_gap_http2_wire_flow_control.ts -o out$i; done
cmp ll1/test_gap_http2_wire_flow_control_ts.ll ll2/test_gap_http2_wire_flow_control_ts.ll   # differs
diff <(sort ll1/*_ts.ll) <(sort ll2/*_ts.ll)                                               # same lines

Example diff:

< @perry_class_shape_id__helpers_h2_wire_ts__RawServerPeer = external global i32
…
> @perry_class_shape_id__helpers_h2_wire_ts__RawServerPeer = external global i32

Also reproduces on test_gap_10485_class_member_var_captures (both its _ts.ll and its _helpers_…_cjs.ll). In a 60-file sample, these 2 programs / 4 modules varied between runs; the rest were stable. The pattern (imported class shape-id globals) suggests a HashMap/HashSet iteration feeding external-global emission.

Found while checking that the WASI codegen work (#11406) leaves host IR byte-identical.