spinel stdlib reach: what can a real handler actually use?

context

the spike proved spinel compiles a web-shaped handler (ENV + stdin + bare
gets + string interpolation + if/elsif). but the edges of spinel's stdlib
coverage are unmapped, and they bound what real handlers can do.

known so far

• ✅ ENV["..."], bare gets loop, String#split/length/chomp/[],
  interpolation, if/elsif, methods, require_relative
• ❌ STDIN.gets (inference treats STDIN as int → emits 0; use bare gets)
• ⚠️ heterogeneous arrays (e.g. [string, proc]) break type inference —
  this is why routing is if/elsif, not a proc-table (see #routing)

probe these, document what compiles

• Hash literals + access ({}, h["k"]) — handlers want key/value
• JSON parse/generate — the real request/response payload format
• regex on a request body / path
• Array of homogeneous structs/values + iteration
• FFI (spinel ships an examples/ffi/sqlite — confirm a handler can
  call a C lib; this is a load-bearing claim of the PRD)
• integer/float math edge cases, to_i/to_f
• string building at volume (response bodies)

deliverable

a docs/spinel-coverage.md table: feature → compiles? → notes/workaround.
this becomes the authoritative "what you can write in a handler" reference,
and tells us which idioms the DSL must avoid.

Start by reviewing the known Spinel stdlib behavior and the examples/ffi/sqlite example, then probe each listed feature for compilation and runtime behavior. Record the results in docs/spinel-coverage.md as a feature, compiles?, and notes/workaround table; done means the table covers every requested probe and documents handler-safe idioms.