feat(optimizer): fold ordering on ASCII char literals (#222) - #288

Closes #222.

What

compareLiterals (né numericCompare, renamed since it now handles more than numbers) gains one arm: ordering comparisons (<, <=, >, >=) on two Char literals fold at compile time when both codepoints are below U+0080.

(LiteralChar _ x, LiteralChar _ y)
  | isAscii x, isAscii y → Just (compare x y)

Why the ASCII gate

Note [Folding primops follows Lua 5.1] holds ordering back because Lua orders strings by bytes while the IR literal carries a semantic codepoint, so a host-side compare could disagree with the runtime on non-ASCII operands. For two ASCII chars the single-byte representation orders identically to the codepoint, so the fold matches the runtime exactly. Non-ASCII chars and String literals stay out of scope; the Note's comparison bullet is updated to record the refinement.

Effect on the CharLiterals golden

The final show ('\t' < '\n') used to compile to a runtime branch on a constant condition:

return Effect_Console_log((function()
  local v_S_221 = "\t" < "\n"
  if v_S_221 then
    return "true"
  elseif false == v_S_221 then
    return "false"
  else
    return error("No patterns matched")
  end
end)())()

With the fold in place the existing downstream rewrites cascade (if true then LT else GT → LT, "…LT" == "…LT" → true, if true then "true" → "true") and the whole block collapses:

return Effect_Console_log("true")()

The hand-verified eval oracle (eval/golden.txt) is unchanged — the module still prints true — so the collapse is semantics-preserving.

Tests

Written test-first (red before the fix): a unit test pins the ASCII fold for all four operators, and a companion test pins the soundness guard — a non-ASCII pair ('é' < 'ê') and a mixed pair ('a' < 'é') are left unfolded. Full cabal test all is green, and the randomized IR Optimizer spec group was stress-run 12 times on fresh seeds with no failures or hangs.