lang: reject mismatched operand types in scalar arithmetic (issue 0055)

lowerBinaryOp derived the result type from the LHS alone and emitted
add/sub/mul/div/mod without checking the RHS, so `s64 + string` lowered
as `add : s64` and reinterpreted the string's bytes — printing garbage
instead of erroring.

Add isArithOperand (int / float / vector / pointer, plus custom int
widths) and, for `+ - * / %`, diagnose `cannot apply '<op>' to operands
of type '<lhs>' and '<rhs>'` and return a placeholder sentinel instead of
the corrupting op. `.unresolved` operands pass through so a type we
couldn't infer is never falsely rejected; the existing optional-unwrap
and int×float promotion are accounted for before the check.

Ordering (`< <= > >=`) and bitwise/shift (`& | ^ << >>`) ops share the
same LHS-derived-type hole and are left as a noted follow-up in the issue.

Regression: examples/214-arith-operand-type-check.sx (s64 + string, and
non-numeric LHS string * s64).

tests/expected/214-arith-operand-type-check.exit

@@ -0,0 +1 @@
+1

tests/expected/214-arith-operand-type-check.txt

@@ -0,0 +1,11 @@
+error: cannot apply '+' to operands of type 's64' and 'string'
+  --> /Users/agra/projects/sx/examples/214-arith-operand-type-check.sx:12:10
+   |
+12 |     x := n + s;     // s64 + string — rejected
+   |          ^
+
+error: cannot apply '*' to operands of type 'string' and 's64'
+  --> /Users/agra/projects/sx/examples/214-arith-operand-type-check.sx:13:10
+   |
+13 |     y := s * n;     // string * s64 — rejected (non-numeric LHS too)
+   |          ^