Worktree i64 globals

[cs01]

i64 integer optimization for global variables

Summary

• Implement findI64EligibleVariables to identify const/let globals with integer literal initializers that can stay as native i64 instead of double
• Wire the analysis into generateGlobalVariableDeclarations so eligible globals are declared as @name = global i64 0 instead of @name = global double 0.0
• Add i64 store path in the global variable initializer to use ensureI64 coercion
• Fix a pre-existing native compiler crash: funcBody.statements wasn't generating a GEP because funcBody (from func.body || {...}) was an opaque i8* — changed to func.body ? func.body.statements : [] to preserve the struct type chain
• Document the || opaque pointer crash pattern in rules.md

Details

Integer optimization already worked inside functions (alloca i64, add i64, icmp eq i64), but top-level globals were always double, forcing sitofp i64 → double conversions. Now const LIMIT = 100 compiles to @LIMIT = global i64 0 with native integer operations.

The analysis is conservative — only integer literals qualify. Variables reassigned with non-integer expressions are demoted back to double. Binary expressions like LIMIT + STEP don't qualify because operand tracking across variables isn't implemented yet.

The main debugging challenge was an intermittent SIGSEGV in the native compiler's findI64EligibleVariables. GDB revealed rax contained ASCII string bytes ("block\0re") being dereferenced as a struct — the function was receiving a BlockStatement* instead of an ObjectArray* for the statements parameter. Root cause: func.body || { statements: [] } produces an opaque i8* in the native compiler, and .statements on an opaque pointer doesn't generate a GEP.

Test plan

• New fixture tests/fixtures/globals/integer-globals.ts tests const/let integer globals, arithmetic, and comparison
• npm test — 244/244 pass
• npm run verify — full 3-stage self-hosting passes
• IR inspection confirms @LIMIT = global i64 0 and @STEP = global i64 0 for const integer globals
• Native compiler stability verified with 30 consecutive runs (30/30 pass)