fix(compile) #1110 + chore(ffi) #1112: re-export-only FFI manifest collection; perry-ffi to crates.io

[proggeramlug]

Summary

v0.5.1010 — two related fixes that fall out of trying to ship @perryts/storekit and similar scoped npm wrappers without a sibling Perry checkout.

• Caller-side call instruction uses per-file-mangled symbol for scoped npm native libs (link fails) — follow-up to storekit#1 / #1085 #1110 — re-export-only paths missed perry.nativeLibrary manifest collection in collect_modules.rs, leaving every downstream module's ffi_signatures empty and producing use of undefined value '@js_storekit_*' LLVM-verifier failures.
• publish perry-ffi to crates.io so npm-packaged native wrappers can resolve it #1112 — perry-ffi is now publishable to crates.io. cargo publish --dry-run -p perry-ffi reaches the upload step cleanly.

Closes #1110, partially closes #1112 (final cargo publish is maintainer's step — needs crates.io credentials).

#1113 and #1114 surveyed but not fixed in this PR — both need substantial follow-up work and the latter needs the user's actual shop-admin repro. Both documented in CHANGELOG with concrete next steps.

#1110 in one paragraph

#1085 skipped the wrapper-symbol registration in import_function_prefixes for direct imports of FFI functions declared in perry.nativeLibrary.functions. But the manifest is only added to ctx.native_libraries in collect_modules.rs's import-walk (line ~700 / ~805) — never in the re-export-walk at line ~954. Programs that reach the FFI-bearing package only through a re-export chain (a wrapper module does export { js_foo } from "@perryts/storekit", the entry imports from the wrapper) ended up with an empty ctx.native_libraries, so ffi_signatures was empty in every codegen pass, lower_call.rs's ffi_signatures.contains_key(name) returned false, and the early js_* direct-call branch emitted a call to the FFI symbol from the consumer's IR without pushing a matching declare external. clang then rejected the IR with use of undefined value '@js_storekit_get_jws'.

Fix: mirror the per-kind manifest collection inside the re-export-walk loop. Plus a defensive change in lower_call.rs — when ffi_signatures knows the name, force the FFI-manifest path even if some other code path registers an entry in import_function_prefixes. Future re-export shapes that leak entries past the per-specifier skip in #1085 are now routed through the FFI path anyway.

#1112 in one paragraph

perry-ffi's only direct reference to perry-runtime::* was a set of #[cfg(all(test, feature = "runtime-link"))] layout-assertion tests. Moving perry-runtime to a path-only [dev-dependencies] entry (no version specifier) lets cargo publish strip it from the published manifest entirely. Layout tests keep working in-tree via the relative path. External wrappers leave the runtime-link feature off and don't pull perry-runtime in — Perry's compiler driver already links libperry_runtime.a into the final binary at compile-time. Added keywords / categories / readme + version on the workspace dep lines for both perry-runtime and perry-ffi. cargo publish --dry-run -p perry-ffi --allow-dirty now reaches Uploading perry-ffi v0.5.1010 ... aborting upload due to dry run.

Open after this PR

• FastifyInstance.server returns a number — blocks ws/http2 upgrade piggybacking #1113 — FastifyInstance.server returns a number rather than an EventEmitter handle, blocking the canonical fastify+ws upgrade-piggybacking pattern. Fix requires either wiring app.server to an EventEmitter-shaped handle (with .on("upgrade", cb) registering a callback that hyper's accept loop invokes when the upgrade headers match) or a new method-dispatch arm. Documented as a "Punted gaps — WebSocket upgrade" item in crates/perry-ext-fastify/src/lib.rs already.
• v0.5.1009 regression: setInterval+async MySQL query loop pegs CPU and wedges Fastify HTTP #1114 — setInterval + async @perryts/mysql query loop wedges the runtime with madvise hot in profile, regressed v0.5.1008 → v0.5.1009. The user's minimal repro didn't trigger it; shop-admin's ~68-server-file shape is too specific to recreate from scratch. Bisect candidates (most fastify-flavoured first): 634e1f58 (fastify non-blocking listen + main-thread pump), 7e3bd5a4 (codegen Tracking: Effect framework end-to-end compat (post-#309 / #310) #321 effect succeed via named-import-of-namespace-reexport), 3856caad (transform async fn early-return followed by an unreached await infinite-loops #1047 async early return + unreached await), 52847008 (jsruntime compat: async lowering blocks self-fetch (express/fastify/nestjs/hono) #1021 V8-fallback CJS require cycles + process.exit shim). Needs the user's actual repro to land cleanly.

Test plan

• reproduce the IR-verifier failure end-to-end: export { ... } from "@perryts/storekit" in wrap.ts, entry imports from ./wrap, await js_storekit_get_jws() inside an async fn → use of undefined value '@js_storekit_get_jws'.
• post-fix: same setup produces a clean .o for both modules; main.ts.o references the plain manifest symbol _js_storekit_get_jws; wrap.ts.o no longer emits the perry_fn_wrap_ts__js_storekit_* wrapper externs at all.
• sanity-check the simple-direct-import path still works (no regression from the defensive force_ffi_path change).
• cargo build --release -p perry-runtime -p perry-stdlib -p perry clean.
• cargo test --release -p perry-ffi -p perry-codegen passes.
• cargo publish --dry-run -p perry-ffi --allow-dirty reaches the upload step.