fix: #835 #846 — auto-link providing crate when codegen emits its FFIs

[proggeramlug]

Summary

When TS code (often inside a perry.compilePackages package) emits a call to an FFI whose implementation lives in perry-stdlib or a perry-ext-* crate, but no matching import "node:…" shows up in ctx.native_module_imports, the link step picks "runtime-only" (or omits the well-known flip), and the linker fails with the symptoms reported on #835 / #846:

• Link failure: needs_stdlib not set when compiled-package code (Effect) references ReadableStream FFIs #835: Undefined symbols: _js_readable_stream_new / _js_readable_stream_controller_* / _js_stream_unwrap_handle — Effect's Stream lowers new ReadableStream(...) and stream-controller methods via paths that don't trip uses_fetch, so needs_stdlib never flips.
• express link-fails: js_node_http_create_server codegen'd but perry-ext-http-server not linked #846: Undefined symbols: _js_node_http_create_server — Express's compiled output emits the server-create FFI from a path that didn't surface node:http in the import set, so perry-ext-http never joins the link line.

Codegen already knows the FFI name at call-emission time. This PR records every such emission against a small registry (OwnerKind::Stdlib or OwnerKind::WellKnown("http") / "streams" / …) and folds the drained set into ctx.needs_stdlib + ctx.native_module_imports right before build_optimized_libs runs — the existing well-known flip + minimal-stdlib feature computation pick up the augmented set unchanged.

Design (per the design note in the issue)

• New module crates/perry-codegen/src/ext_registry.rs:
  • Static FFI_REGISTRY table mapping each affected FFI symbol → providing crate.
  • Process-wide Mutex<HashSet<OwnerKind>> collector populated by codegen.
  • take_used_providers() drain consumed by the CLI driver.
• crates/perry-codegen/src/block.rs: single-line hook in LlBlock::call and LlBlock::call_void. Inert for symbols not in the registry.
• crates/perry/src/commands/compile.rs: drains at the start of run_with_parse_cache (so a stale perry dev set can't bleed in) and once before build_optimized_libs, routing entries through the existing flip mechanisms.

Registry coverage today: all Web Streams (js_readable_stream_* / js_writable_stream_* / js_writer_* / js_reader_* / js_transform_stream_* / js_stream_unwrap_handle) → Stdlib; all js_node_http* / js_node_https* / js_node_http2* server FFIs → WellKnown("http") (routes to perry-ext-http which rlibs in perry-ext-http-server).

Test plan

• cargo test --release -p perry-codegen ext_registry — new unit test covers Stdlib + WellKnown routing plus a non-registered FFI control.
• cargo test --release --workspace --exclude perry-ui-ios --exclude perry-ui-tvos --exclude perry-ui-watchos --exclude perry-ui-visionos --exclude perry-ui-android --exclude perry-ui-windows --exclude perry-ui-gtk4 — full sweep, no regressions.
• Spot-check gap tests (test_gap_async_advanced, _class_advanced, _array_methods, _bigint) still link as runtime-only and match Node byte-for-byte — the hook is inert when no listed FFI is emitted.
• cargo fmt --all --check clean.
• Repro programs in /tmp/perry-b1-repro-{835,846}/ — new ReadableStream({...}) and createServer((req,res) => …) link cleanly with no explicit node:* import in the entry TS.
• Inverse check with PERRY_DISABLE_WELL_KNOWN=1 still surfaces the original express link-fails: js_node_http_create_server codegen'd but perry-ext-http-server not linked #846 link error (confirms the well-known flip is the consumer my fix feeds).

Closes #835
Closes #846