JIT: make global environment load witness deterministic after optimizer publication

Problem

vm.test.vm: optimizer executes a global environment load natively intermittently fails after the optimizer artifact has been published:

expected <environment address>, found 0
src/vm.zig:17384

The test assumes one direct call after artifact publication must execute the optimizer and publish the global-binding proof cache. Under a full 10-shard unit run that call can still use a lower tier; a focused 20-run loop reproduced the zero environment_token failure.

Evidence

• Full gate: 2,582 passed, 1 skipped, 1 failed, 0 leaked; only this test failed.
• Immediate focused rerun passed in 75 ms.
• Repeated focused runs reproduced the failure in 3.477 s.
• The artifact and native-operation descriptor exist in both outcomes; only the environment proof remains unpublished in the failing outcome.

Definition of done

• The witness waits for or deterministically drives optimizer execution rather than assuming one post-publication call is sufficient.
• It still proves that the native global-load callback populated the exact environment and shape tokens.
• It retains bounded compile-count and exact step-accounting assertions.
• Repeated focused runs pass.
• The full sharded unit suite passes with zero failures and leaks.

Fixed and pushed to main in 20044bc3.

The initial issue diagnosis was slightly off: optimizer execution was occurring, but hash-table mirror order could place Number in one of the four inline global-object slots, which this external-slot cache intentionally refuses. The fixture now occupies inline storage first and asserts that Number is eligible. The shared-mode companion uses the same eligible layout, so synchronization policy is the reason its cache remains cold.

Evidence:

• native global-load witness passes 50/50 fresh-process focused repetitions;
• shared-mode cache-refusal witness passes;
• final full unit gate at f9ed7030: 2,583 passed, 1 skipped, 0 failed, 0 leaked in 561.9 s.