Link failure: `needs_stdlib` not set when compiled-package code (Effect) references ReadableStream FFIs

[proggeramlug]

Surfaced trying to compile the new canonical Effect e2e program (`test-files/compat-e2e/effect/main.ts`, added under #802) with v0.5.914.

Symptom

```
Linking (runtime-only)...
Undefined symbols for architecture arm64:
"_js_readable_stream_controller_close"
"_js_readable_stream_controller_enqueue"
"_js_readable_stream_controller_error"
"_js_readable_stream_new"
"_js_stream_unwrap_handle"
ld: symbol(s) not found for architecture arm64
Error: Linking failed
```

Root cause

These FFIs are exported with `#[no_mangle] pub unsafe extern "C" fn` from `crates/perry-stdlib/src/streams.rs` — they exist in `libperry_stdlib.a`. The link step picked the "runtime-only" path ("Linking (runtime-only)...") because `ctx.needs_stdlib` is false.

`needs_stdlib` is currently set only from explicit imports of `node:` modules (`crates/perry/src/commands/compile/collect_modules.rs:430-451`, via `perry_hir::requires_stdlib`). When a compiled-package (Effect) uses `ReadableStream` internally, codegen emits calls to `js_readable_stream_new` / `js_readable_stream_controller_` / `js_stream_unwrap_handle` (`crates/perry-codegen/src/lower_call/builtin.rs:571`, `lower_call.rs:5036`, `runtime_decls.rs:1256`), but `needs_stdlib` never flips, so `libperry_stdlib.a` is not linked → undefined symbols.

Why this matters

This is a class of bug, not a single missing symbol. Anytime codegen lowers something to an FFI call without a corresponding stdlib-import detection step, the binary link-fails when the call site is inside a compiled package (and works when the call site is reachable via a `node:*` import, because the import sets the flag).

Fix sketch

Either:

1. Per-FFI side-effect flag: when codegen lowers a call that targets a `js_*` symbol exported only from `libperry_stdlib` (not `libperry_runtime`), record `ctx.needs_stdlib = true` at the codegen call site.
2. Belt-and-suspenders link strategy: always link `libperry_stdlib` (relying on `strip_dedup` / GC-sections to keep binary size bounded). Simpler but cedes some size budget.

Option 1 is the cleaner long-term fix and aligns with how `needs_thread` and `needs_plugins` are tracked.

Repro

```bash
cd test-files/compat-e2e/effect
npm install
perry main.ts -o out
```

Surfaces from any compiled-package use of `new ReadableStream({ ... })`; not specific to Effect.

Part of #793 + #321. Surfaced by the #802 e2e scaffold.

[proggeramlug]

Update — narrowed the root cause further:

`js_readable_stream_` and `js_stream_unwrap_handle` are exported from `crates/perry-stdlib/src/streams.rs` (39 `js_` FFI exports total in that file). But the manifest classifies `stream` as runtime-only:

```rust
// crates/perry-api-manifest/src/entries.rs
pub const RUNTIME_ONLY_MODULES: &[&str] = &[
"fs", "path", "os", "buffer", "child_process",
"stream", // ← but the impl lives in perry-stdlib, not perry-runtime
...
];
```

`is_runtime_only_module("stream")` returns true → `requires_stdlib` returns false → even an explicit `import "node:stream"` in user code does NOT flip `ctx.needs_stdlib`, because the manifest says stream doesn't need stdlib.

So the workaround "add a node:stream import to force the link" does not work either — confirmed by a second compile attempt with `import "node:stream";` at the top of the Effect program. Same five undefined symbols.

The fix is one of:

1. Move stream FFIs into perry-runtime. Aligns the implementation with the manifest's claim.
2. Remove `stream` from `RUNTIME_ONLY_MODULES`. Forces stdlib link when any user imports stream. May regress binary-size for programs that import `node:stream` for types only.
3. Per-FFI tracking at the codegen site (preferred). Mirrors how `needs_thread` is flipped — when the codegen emits a call to a stdlib-only symbol, bump `ctx.needs_stdlib`. This is independent of any import the user wrote.

Option 3 generalizes: 35 `perry-ext-*` crates and several other stdlib modules will hit the same shape eventually (the issue isn't "streams specifically," it's "codegen emits an FFI that the manifest doesn't know about").