fix(std): render integer formatter extremes — i64::MIN and unsigned all-ones [F0.8]

Resolves issue 0090. The `{}` integer formatter mis-rendered both ends of
the 64-bit range:

- `int_to_string` computed the magnitude as `0 - n`, which overflows for
  `s64::MIN` (its magnitude is unrepresentable as a positive s64) — the
  value stayed negative, the digit loop ran zero times, so only `-`
  printed. It now extracts digits straight from `n` (per-digit
  `|n % 10|`, `n` truncating toward zero), never negating MIN.

- `any_to_string`'s `case int:` formatted every integer as s64, so a u64
  all-ones value printed as `-1`. There was no `uint` type-category to
  distinguish signedness. Added an additive `type_is_unsigned(T)`
  reflection builtin (static fold + dynamic interp/LLVM paths, mirroring
  `type_name`), backed by the new `TypeTable.isUnsignedInt` predicate, and
  a `uint_to_string` formatter (unsigned decimal via long-division over
  four 16-bit limbs). `case int:` routes through `type_is_unsigned(type)`.

The 16-bit-limb split is factored into a shared `decompose_u16x4`, now
reused by `int_to_hex_string` (no second unsigned-math routine).

Regression: examples/0046-basic-int-formatter-extremes pins both extremes
plus a width spread; unit tests cover `isUnsignedInt`. Docs (specs.md
representation note, readme std API) updated for unsigned/extreme `{}`
behavior. IR snapshots refreshed for the two new std functions.

examples/expected/0046-basic-int-formatter-extremes.stdout

@@ -0,0 +1,10 @@
+s64.min=-9223372036854775808
+s64.max=9223372036854775807
+u64.max=18446744073709551615
+s8.min=-128 s8.max=127
+s16.min=-32768 s16.max=32767
+s32.min=-2147483648 s32.max=2147483647
+u8.max=255 u16.max=65535
+u32.max=4294967295
+u8.min=0 u64.min=0 zero=0
+neg=-42 pos=4000000000