feat(WebClient): add Node.js support

[JereSalo]

Adds a Node.js build of the web client using napi-rs. The same Rust crate compiles to both wasm32 (browser, via wasm-bindgen) and native (Node.js, via napi-rs) using mutually exclusive feature flags (browser vs nodejs).

#[js_export] macro

A new proc macro replaces #[wasm_bindgen] on exported items. It expands to #[cfg_attr(feature = "browser", wasm_bindgen)] + #[cfg_attr(feature = "nodejs", napi)]. When a method uses JsU64 in its signature (u64/BigInt on browser, f64/number on Node.js), the macro splits it into two platform-specific impl blocks automatically.

A platform.rs module provides type aliases that switch per feature (JsErr, JsBytes, AsyncCell, ClientAuth, etc.), letting most methods be written once. Only create_client, create_mock_client, and settings need separate implementations due to fundamental platform differences (IndexedDB vs SQLite, WebKeyStore vs FilesystemKeyStore).

Note on the macro: We could theoretically remove the macro but it might be worth keeping it in order to reduce the amount of lines and boilerplate we have in the rest of the code. It's just a tradeoff that we might want, but in case there's a strong reason for removing it we could do it.

Single npm package with conditional exports

The same @miden-sdk/miden-sdk package now works in both browser and Node.js. Users write the same import in both environments:

import { MidenClient } from "@miden-sdk/miden-sdk";
const client = await MidenClient.create({ rpcUrl: "testnet" });

The package.json uses conditional exports ("browser" and "node" conditions) so the runtime or bundler automatically selects the right entry point. The browser entry (dist/index.js) loads WASM + IndexedDB. The Node.js entry (js/node-index.js) loads the napi native binary + SQLite. The MidenClient class and all resource classes (accounts, transactions, notes, etc.) are shared between both backends.

A Node.js normalization layer (js/node/) handles API differences between napi and wasm-bindgen: BigInt to Number conversion, null to undefined for Option types, snake_case method aliases, and array type polyfills.

Platform binary distribution

Native Node.js binaries are distributed via platform-specific npm packages (@miden-sdk/node-darwin-arm64, @miden-sdk/node-darwin-x64, @miden-sdk/node-linux-x64-gnu). These are listed as optionalDependencies (injected at publish time) so npm installs only the matching platform. A loader with fallback to the local target/ directory supports development without prebuilt binaries.

Note: We inject optional dependencies at publish time because if they were in the package.json then yarn install would fail because it tries to get those packages from npm and they don't exist yet.

Publishing changes

The existing publish workflows (publish-web-client-next.yml and publish-web-client-release.yml) now include a matrix build step that compiles native binaries on 3 platforms (macOS ARM, macOS x64, Linux x64) and publishes the platform packages before the main package. The js-export-macro crate is enabled for publishing to crates.io as users need it to compile miden-client-web.

Platform-agnostic tests

20 test files were rewritten to a platform-agnostic format using a run fixture that abstracts the runtime:

test("creates a wallet", async ({ run }) => {
  const result = await run(async ({ client, sdk }) => {
    const wallet = await client.newWallet(
      sdk.AccountStorageMode.private(), true, sdk.AuthScheme.AuthRpoFalcon512
    );
    return { id: wallet.id().toString() };
  });
  expect(result.id).toMatch(/^0x/);
});

On Node.js, run calls the callback directly with a napi client (SQLite store). On browser, it serializes the callback and executes it inside a page via page.evaluate() (WASM + IndexedDB). A normalization layer handles API differences between platforms (null to undefined, BigInt to Number, method name aliases).

7 browser-only test files (store_isolation, sync_lock, import_export, etc.) are skipped on Node.js.

Additional Notes

• Maintained WASM test coverage despite the test migration
• Tested release and publish flow in my personal fork so that we know it's going to work. Also, WASM is still published even if the NodeJS part fails for some reason.

Closes #1667

[JereSalo]

Note that there may be some NodeJS specific things to improve, but if possible we should try to focus the review on the broader changes that may have an impact in the existing codebase. Any details of NodeJS can be addressed in follow-ups if they are not important. I just leave this comment because the PR is incredibly large and it's best to address the most relevant things now and if it's mergeable we can go for it and leave the rest of the points to tackle in a follow-up issue.

[lima-limon-inc]

I like the js_export macro idea! It's a shame that it has to be shipped separately :(.

AFAIK, this is a pain point that other projects also encounter (stadiamaps/ferrostar#289 comes to mind).

I left a couple of comments, mainly regarding readability.

[lima-limon-inc]

Why are checking if the method has U64? Could we leave a comment explaining the rationale?

Edit: Found out why a bit below, maybe it'd be worth pointing to the make_platform_method in a comment

Edit 2: I also read that it's on top level doc!

[lima-limon-inc]

nit: Maybe to increase readability a bit I would a couple of comments stating what we're doing.
Mainly because syn's API can be a bit unintuitive from time to time.

[lima-limon-inc]

In the context of js bindings, functions can only be methods of structs, correct?

If that's the case, maybe I'd add a comment with a link to the docs. So that code that reflects this (e.g. [methods](So things like https://github.com/0xMiden/miden-client/pull/1908/changes#diff-2d13f93b3c68ba298247a3786c2780f5aea5b651ff05948645a918d6f8695b30R87
)) are also explained in the code.

[lima-limon-inc]

nit: I'm not sure I understand the rationale behind fn extract_stashed_args(method: &mut ImplItemFn) -> TokenStream2 {

It seems to me that we are adding the __js_export_args argument on line 95, just so we can remove it later on line 169, inside the make_platform_method.

Can't this flow be unified on one place?