lang: rename signed integer types sN -> iN

Surface rename of the signed integer family: s1..s64 become i1..i64
(u1..u64, usize, isize unchanged). 'string' keeps the s-prefix arm in
name classification; width parsing moves to the i-prefix arm next to
isize.

Internal TypeId tags follow the surface (.s8/.s16/.s32/.s64 ->
.i8/.i16/.i32/.i64), as do mono-key mangle fragments (ptr_i64,
tu_i64_bool) and all display/diagnostic formatting (i{d}).

Migrated in the same sweep: stdlib + examples + issue repros + FFI C
companions (shared symbol names like ffi_id_i64), expected
stdout/stderr/ir snapshots, specs.md, readme.md, CLAUDE.md/AGENTS.md,
implementation_plan.md, docs/, issue writeups. Vendored stb_image and
historical flow state left untouched.

zig build test: 426/426; examples suite: 595/595.

issues/0093-global-raw-value-numeric-limit-shadow.md

@@ -21,14 +21,14 @@
 > - `src/ir/expr_typer.zig` — numeric-limit inference arm: the `shadowed`
 >   check now calls the same helper.
 >
-> A bare `f64.epsilon` / `s32.max` (a `.type_expr` receiver, never an
+> A bare `f64.epsilon` / `i32.max` (a `.type_expr` receiver, never an
 > `.identifier`) still folds, even when a global or module-const raw value of
 > the same spelling exists — the bare receiver is never value-shadowed.
 > Float-only-on-int and non-numeric-receiver errors are unchanged.
 >
 > Regression: `examples/0161-types-numeric-limit-value-shadow.sx` now exercises
-> all three binding kinds — a GLOBAL `` `f32 ``, a MODULE-CONST `` `s16 ``, and
-> LOCAL `` `f64 ``/`` `s32 ``/`` `u8 `` — each reading its field while the bare
+> all three binding kinds — a GLOBAL `` `f32 ``, a MODULE-CONST `` `i16 ``, and
+> LOCAL `` `f64 ``/`` `i32 ``/`` `u8 `` — each reading its field while the bare
 > spelling still folds. Unit test `src/ir/expr_typer.test.zig` pins the global
 > + module-const sources. NL.1 (`examples/0148`) / NL.2 (`examples/0159`,
 > `examples/0160`) unregressed.
@@ -40,20 +40,20 @@
 Field access on a **global** raw reserved-spelled value binding is interpreted as
 a builtin type numeric-limit access instead of an ordinary value field access.
 Observed: the repro prints `0.000000 2147483647` (`f64.epsilon` /
-`s32.max`). Expected: it prints `12 78` from the `Box` fields.
+`i32.max`). Expected: it prints `12 78` from the `Box` fields.
 
 ## Reproduction
 
 ```sx
 #import "modules/std.sx";
 
-Box :: struct { epsilon: s64; max: s64; }
+Box :: struct { epsilon: i64; max: i64; }
 
 `f64 := Box.{ epsilon = 12, max = 34 };
-`s32 := Box.{ epsilon = 56, max = 78 };
+`i32 := Box.{ epsilon = 56, max = 78 };
 
-main :: () -> s32 {
-    print("{} {}\n", `f64.epsilon, `s32.max);
+main :: () -> i32 {
+    print("{} {}\n", `f64.epsilon, `i32.max);
     return 0;
 }
 ```
@@ -66,7 +66,7 @@ at `Lowering.lowerNumericLimit` and the new issue-0092 guard around
 `Scope.lookup`. That guard returns `null` for a shadowing local, but global raw
 bindings are registered in `ProgramIndex.global_names` (and module constants in
 `ProgramIndex.module_const_map`), not in `Scope`, so an `.identifier` receiver
-whose text is `f64` / `s32` still folds to a numeric limit before ordinary
+whose text is `f64` / `i32` still folds to a numeric limit before ordinary
 global field lowering can read the value. Mirror the same rule in
 `src/ir/expr_typer.zig` so inferred types match lowering.
 
@@ -74,7 +74,7 @@ Likely fix: for `.identifier` numeric-limit receivers, prefer any in-scope value
 binding source over the builtin-type fold: lexical `Scope.lookup`, global values
 (`program_index.global_names`), and module value constants where applicable.
 Keep `.type_expr` receivers folding as type receivers, so bare `f64.epsilon` and
-`s32.max` still fold even when a raw global value of the same spelling exists.
+`i32.max` still fold even when a raw global value of the same spelling exists.
 
 Verification: pin the repro above as a regression. It should print `12 78`.
 Also verify the existing numeric-limit examples still pass: