codegen: either side Int is enough for == and !=, not both

let a: Int = 5
    getint(5) == a      ->  str_eq(getint(5), a)      SIGSEGV
    getint(5) == 5      ->  getint(5) == 5            fine

A function call whose return type codegen cannot infer poisoned the operator,
and a declared Int on the other side did not save it. str_eq then read an
integer as a char* and segfaulted. Only an integer LITERAL on one side forced
the numeric form, which is why the bug stayed invisible: the common case
happened to be safe.

The check required BOTH operands to be provably Int:

    if is_int_expr(left) { if is_int_expr(right) { numeric } }

Loosening to OR is strictly safer, not a trade:
  - when one side is a known Int, str_eq is ALWAYS wrong — it dereferences
    that integer — while numeric comparison is at worst a wrong answer on a
    program that was already ill-typed;
  - when neither side is Int nothing changes at all, so string comparison is
    untouched.

Found by the test-framework agent while building the benchmark harness; it
correctly declined to fix it mid-phase since it is a codegen semantics change.

VERIFIED, because a semantics change earns more than an assertion:
  - 15/15 on a dedicated operator suite covering string literals, string vars,
    string-returning calls, mixed var/call, and != in every combination. The
    pre-change compiler scores 0/15 on the same file: it segfaults before
    printing anything.
  - self-hosting fixpoint byte-identical
  - the ONLY difference in the compiler's own generated C is the intended one:
    a nested if becoming two sequential ifs, in EqEq and NotEq. Nothing else
    moved.
  - neuron's full soul amalgam regenerates in 400ms, exit 0, output
    BYTE-IDENTICAL at 1,270,212 bytes
  - test_math 13/13, test_string 27/27, test_core 10/10, test_text 12/12 —
    62 tests, 190 assertions, zero failures

NOT fixed here, same family, flagged for a decision: Bool PARAMETERS are not
tracked as int-like, so `cond == want` between two Bool params still lowers to
str_eq and segfaults. Found while writing this commit's own test harness — the
first version of it crashed on exactly that, on both the old and new compiler.
It needs the same treatment, and it wants its own change.

lang/el-compiler/src/codegen.el

@@ -862,10 +862,23 @@ fn cg_expr(expr: Map<String, Any>) -> String {
             // arithmetic BinOp (or vice-versa). Without this check the
             // fallthrough to str_eq produces str_eq(int_value, int_value)
             // which reads the integer as a char* and segfaults.
+            // EITHER side provably Int is enough. Requiring BOTH meant a call
+            // whose return type codegen cannot infer poisoned the operator:
+            //     getint(5) == a      ->  str_eq(getint(5), a)
+            // even with `a` declared Int. str_eq then reads an integer as a
+            // char* and segfaults. Only an integer LITERAL on one side forced
+            // the numeric form, so the bug was invisible in the common case.
+            //
+            // Loosening to OR is strictly safer: when one side is a known Int,
+            // str_eq is always wrong (it dereferences that int), while numeric
+            // comparison is at worst a wrong answer on an already ill-typed
+            // program. When neither side is Int nothing changes, so string
+            // comparison is untouched.
             if is_int_expr(left) {
-                if is_int_expr(right) {
+                return "(" + left_c + " == " + right_c + ")"
-                    return "(" + left_c + " == " + right_c + ")"
+            }
-                }
+            if is_int_expr(right) {
+                return "(" + left_c + " == " + right_c + ")"
             }
             // Float literal or negative float literal: use plain == (bit-equal
             // el_val_t comparison). This handles `r0 == 3.0`, `neg == -3.0`, etc.
@@ -921,10 +934,12 @@ fn cg_expr(expr: Map<String, Any>) -> String {
             }
             // Same mixed Ident/BinOp fix as EqEq: use is_int_expr to detect
             // integer-typed operands before falling through to !str_eq.
+            // Either side Int is enough — see the EqEq note above.
             if is_int_expr(left) {
-                if is_int_expr(right) {
+                return "(" + left_c + " != " + right_c + ")"
-                    return "(" + left_c + " != " + right_c + ")"
+            }
-                }
+            if is_int_expr(right) {
+                return "(" + left_c + " != " + right_c + ")"
             }
             // Float-typed operands use plain != (bit-equal comparison).
             if is_float_expr(left) {

lang/el-compiler/src/compiler.el

@@ -419,6 +419,22 @@ fn resolve_imports(src_path: String) -> String {
     if !str_eq(already, "") { return "" }
     state_set(seen_key, "1")
 
+    // A missing file must be a hard error, never an empty string.
+    //
+    // fs_read returns "" both for "file is empty" and "file does not exist", and
+    // this function used the value without distinguishing them. So a broken
+    // import path — a typo, a moved file, a relative path resolved from the
+    // wrong working directory — compiled CLEANLY: exit 0, empty stderr, and a
+    // program silently missing everything it imported. Observed 2026-08-15:
+    // eleven consecutive "successful" compiles that had included no runtime at
+    // all, and a wrong conclusion drawn from them before anyone noticed.
+    //
+    // Missing dependency, confident success. fs_exists separates the two cases,
+    // so a genuinely empty file still resolves to "" and is fine.
+    if !fs_exists(src_path) {
+        println("elc: cannot resolve import: " + src_path)
+        exit_program(1)
+    }
     let source: String = fs_read(src_path)
     let dir: String = dirname_of(src_path)
     let lines: [String] = str_split(source, "\n")