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.
The count description claimed every count must be "positive integral",
which is wrong: zero is context-dependent. Verified at HEAD — an array
dimension (`[0]s64`) and a generic value-param count (`Box(0)`, $N:u32)
both accept zero as a length-0 instantiation, while a `Vector` lane
count stays strictly positive (`Vector(0,f32)` rejected). Negatives are
rejected for array dims and unsigned value-params, but a signed
value-param accepts a negative; only the integral requirement (folds
4.0, rejects 4.5) is common to all three.
Split the count paragraph into per-consumer bullets stating the exact
range each accepts. Range-bound paragraph unchanged. Pin the zero
contrast with examples 0147 (array-dim + value-param zero accepted) and
1505 (Vector zero-lane rejected). No compiler-code change.
