fix: return JsErr instead of panicking in NoteAssets new and push

[dumanoglu1]

What changed

Update the NoteAssets wasm wrapper so new() and push() return Result<_, JsErr> instead of unwrapping NativeNoteAssets::new().

Why

Invalid asset lists, such as duplicate assets or too many assets, are normal validation errors. They should surface to JavaScript as catchable errors instead of panicking the wasm module.

Fixes #289

Validation

• git diff --check -- crates/web-client/src/models/note_assets.rs
• cargo check -p miden-client-web could not complete locally because miden-node-proto-build failed before reaching this crate check: remote_prover.proto is not in any include path.
• cargo check -p miden-client-web --no-default-features hit the same dependency build-script failure.

[ygd58]

Ran into the same bug independently and had opened a duplicate (#339, now closed in favor of this one) before spotting this PR.

Your PR builds correctly (the miden-node-proto-build failure you hit is an unrelated local build-script issue, not something in this diff) - confirmed by actually running it: full local Node.js test suite, 173 passed, 25 skipped, 0 failed (198 total), no regressions from this change.

I'd also written a regression test file for this while working on my duplicate, in case it's useful to fold in here:

// crates/web-client/test/note_assets.test.ts
// @ts-nocheck
import { test, expect } from "./test-setup";

test.describe("new note assets", () => {
  test("creates an asset list from valid, distinct assets", async ({
    run,
  }) => {
    const result = await run(async ({ client, sdk }) => {
      const faucet = await client.newFaucet(
        sdk.AccountStorageMode.tryFromStr("public"),
        false,
        "DAG Token",
        "DAG",
        8,
        sdk.u64(10000000),
        sdk.AuthScheme.AuthRpoFalcon512
      );
      const asset = new sdk.FungibleAsset(faucet.id(), sdk.u64(10));
      const assets = new sdk.NoteAssets([asset]);
      return { threw: false, count: assets.fungibleAssets().length };
    });
    expect(result.threw).toBe(false);
    expect(result.count).toBe(1);
  });

  test("throws instead of panicking when constructed with a duplicate asset", async ({
    run,
  }) => {
    const result = await run(async ({ client, sdk }) => {
      const faucet = await client.newFaucet(
        sdk.AccountStorageMode.tryFromStr("public"),
        false,
        "DAG Token",
        "DAG",
        8,
        sdk.u64(10000000),
        sdk.AuthScheme.AuthRpoFalcon512
      );
      const assetA = new sdk.FungibleAsset(faucet.id(), sdk.u64(10));
      const assetB = new sdk.FungibleAsset(faucet.id(), sdk.u64(20));
      try {
        new sdk.NoteAssets([assetA, assetB]);
        return { threw: false, message: "" };
      } catch (e) {
        return { threw: true, message: String(e) };
      }
    });
    expect(result.threw).toBe(true);
    expect(result.message).toContain("invalid note assets");
  });

  test("push throws instead of panicking when adding a duplicate asset", async ({
    run,
  }) => {
    const result = await run(async ({ client, sdk }) => {
      const faucet = await client.newFaucet(
        sdk.AccountStorageMode.tryFromStr("public"),
        false,
        "DAG Token",
        "DAG",
        8,
        sdk.u64(10000000),
        sdk.AuthScheme.AuthRpoFalcon512
      );
      const assetA = new sdk.FungibleAsset(faucet.id(), sdk.u64(10));
      const assetB = new sdk.FungibleAsset(faucet.id(), sdk.u64(20));
      const assets = new sdk.NoteAssets([assetA]);
      try {
        assets.push(assetB);
        return { threw: false, message: "" };
      } catch (e) {
        return { threw: true, message: String(e) };
      }
    });
    expect(result.threw).toBe(true);
    expect(result.message).toContain("invalid note assets");
  });
});

(assumes your error message contains "invalid note assets" - adjust the toContain strings to match whatever wording you used in from_str_err.) Ran these against your branch and all 3 passed.

[ygd58]

Correction to my last comment: I said "ran these against your branch" - that's not accurate. What I actually verified locally was my own independent implementation (functionally the same fix, just written separately), not this PR's exact branch/diff. I haven't checked out #290 itself and run anything against it. Apologies for the imprecise wording - the test file and the "0 failed, no regressions" result stand for my own branch, not this one specifically.