Set up the gem skeleton and boot an embedded CRuby VM inside the NSGI cdylib

[himura467]

Goal

Set up the gem skeleton and the embeddable Ruby VM so later phases have a foundation to build on.

Tasks

• Gem skeleton: gemspec, lib/nsgi.rb, Rust cdylib under ext/, Cargo workspace depending on nsgi = "0.1" (published protocol crate) + rb-sys with the link-ruby feature
• VM embedding: boot CRuby on a dedicated thread at first nsgi_handle call (ruby_init, load path setup)
• App discovery: host_ctx is opaque per spec, so the app file is located out-of-band via NSGI_APP=./app.rb
• Build tooling: rake compile (or equivalent) producing the cdylib; CI matrix (Ruby 3.2+, Linux/macOS)

Notes

Rust is chosen over plain C because the ABI types come for free from the nsgi crate, and catch_unwind + ownership directly serve the protocol's no-unwind-into-host rule.

[himura467]

Initial implementation landed on main (pending commit): Cargo workspace with the cdylib crate (`ext/nsgi`, depending on `nsgi = "0.1"` + `rb-sys` with `link-ruby`), pure-Ruby side under `lib/`, gemspec, and `examples/hello.rb`. The VM boots on a dedicated 16 MB-stack thread on first `nsgi_handle` call; the app file comes from `NSGI_APP` and the gem lib dir from `NSGI_LIB`.

One hard-won discovery worth recording: bare `ruby_setup()` leaves the VM half-initialized. `rb_call_builtin_inits`, which loads the Ruby-defined core methods (`Kernel#warn`, `Kernel#Integer`, ...), only runs during option processing, so those methods simply do not exist and calls fail with confusing `undefined method '#Symbol:0x...'` errors (the call-site IDs point at symbols the half-booted VM never interned; the embedded VM had 1836 symbols vs 3815 in the CLI). The fix is the canonical embedding sequence: `ruby_init_stack` + `ruby_setup()` + `ruby_options("-e", "0")` + `ruby_exec_node`.

Remaining for this issue: rake-based build entry point and the CI matrix.

[himura467]

CI landed in feaec63 (PR #9): Linux + macOS matrix with ruby/setup-ruby 3.4 and stable Rust, building the workspace, running the mock host suite, and memory-checking with valgrind (Linux) and leaks (macOS). A rake-based gem build entry point remains open until the gem packaging story (shipping a prebuilt cdylib vs building on install) is decided; everything else here is done.