feat(stdlib): add list get/get?/index/index? accessors 🎯

[timfennis]

Context

Follow-up to #167, which added list.get?. A Codex review of that PR found
get? crashed on large indices: it took an i64, and the #[function] macro's
integer extractor rejects BigInt values before the function body runs — even
though a BigInt has static type Int and passes call resolution. So
[1].get?(10^40) raised arg 1: expected int, got object instead of behaving
like the advertised safe lookup.

Fixing that cleanly meant settling how list element access should work in
general, which is now a 2×2 matrix.

Element accessors

function	index argument	negative index	out of bounds
get	usize	error	error
get?	usize	error	None
index	BigInt	wraps from end	error
index?	BigInt	wraps from end	None

The argument type decides negative handling: get/get? take a usize, so a
negative index is a conversion error; index/index? take a signed BigInt
and wrap from the end like the [] operator. The ? suffix decides
out-of-bounds handling (error vs None). index is the named form of [];
index? is its non-throwing twin (there is no []?).

Primary changes

• ndc_macros/src/vm_convert.rs — the usize argument extractor now
  converts via to_number() + TryFrom<Number> for usize, accepting both Int
  and BigInt and raising a clear error on negative/oversized values. This is
  what lets get/get? reject negatives at the conversion layer, and it fixes
  the BigInt crash. It also fixes a latent bug: the old *i as usize silently
  wrapped a negative index to a huge usize for every usize builtin
  (insert, truncate, …).
• ndc_stdlib/src/list.rs — adds get, index, index? and reworks get?
  onto the usize signature, plus a small wrap_index helper for the signed
  variants.
• ndc_core/src/num.rs — clearer NumberToUsizeError messages (the old
  BigInt one leaked internal conversion jargon).
• Docs — option.md and list.md document the four accessors.
• Tests — 601_stdlib_list/004–012 cover the success and error paths,
  including the previously-crashing get?(-1) and get?(10^40).

Notes for reviewers

• The usize-extractor change is the widest-reaching part: it affects all
  usize builtins, so error messages for bad size/index arguments changed. The
  full test suite passes (427 tests).
• index/index? are list-only element access (no range/slice support); the
  [] operator still owns slicing and other container types.

🤖