fix(web-client): follow the rc.6 account and note file format

[WiktorStarczewski]

Client PR: #2594

Account and note files follow protocol 0.17.0-rc.6. miden_client::notes is gone, AccountFile fields are private, and both files encode as protobuf.

• NoteFile comes from miden_client::note.
• Import uses account() and into_parts().
• serialize / deserialize call to_bytes / try_from_bytes. Bytes from 0.17.0-rc.1 do not decode.

Cargo.toml stays on published miden-client 0.17.0-rc.1. CI injects the linked head. Do not merge on the readiness gate alone: that gate goes green when rust-sdk #2594 reaches next, while this tree still does not compile against the published client. Bump the client pin to the release that contains #2594 before merging.

Reviewers: the byte-format break is the part worth your time.

[github-actions]

🔗 Linked client PR: 0xMiden/rust-sdk#2594

Field	Value
Patched at	0xMiden/rust-sdk@jmunoz-protocol-0.17.0-rc.6
Pin (head sha)	1e45cfda68993a3f6807f6ac9d25bfc66564e957
Upstream state	open (merged: false)

This run is testing against the linked PR's head. The published artifact will use the canonical miden-client source — CI on main/next does not auto-patch.

Local-dev parity:

scripts/dev-with-client-pr.sh 2594    # apply the same patch locally
scripts/dev-with-client-pr.sh --clear                            # remove it before commit

[github-actions]

➖ WASM proving — No significant change (largest prove / consume / ecdsa-k256-keccak -0.36%, floor ±1.90%)

Head	80f39fa
Base	85a73e3 (next)
Method	mean of per-rep fastest, 6 reps × 3 warm proves, release / mt, 8 threads on warp-ubuntu-latest-x64-8x — lower is better
Workload	1 benchmark (ms) — prove / consume / ecdsa-k256-keccak

	Benchmark	Base (ms)	Head (ms)	Δ	Δ %
➖	prove / consume / ecdsa-k256-keccak	2,841.8	2,831.7	-10.1	-0.36%

Methodology and raw samples

• The timed interval is the proveTransaction call on a client constructed without a web worker. Prover construction, transaction execution, the faucet draw and the production worker round-trip are outside it, so a change confined to any of those does not move this number.
• The run configuration below — runner, profile, variant, thread count, repetition and prove counts — is reported by the benchmark job, which runs from this pull request's own code. It describes what that job says it did. Every figure and every verdict above is recomputed here from the raw samples.
• Each benchmark keeps 6 reps × 3 warm proves on warp-ubuntu-latest-x64-8x (8 threads, release / mt). One extra repetition and the first prove of every page run first and are discarded.
• The reported figure is the mean of each repetition's fastest prove. Within one repetition every prove is bit-identical work, so interference — which only ever adds time — is all that varies, and the repetition's fastest prove is its best observed warm prove — a lower-tail statistic, not a measured "clean" cost, and so blind to a regression that leaves the best case alone (see the mean cross-check). Across repetitions the faucet differs, which shifts the proof-of-work grind, so averaging the per-repetition minima shrinks that lottery — it averages the grind down rather than cancelling it, because each side draws its own.
• Measured over six calibration runs of identical binaries, this estimator holds a standard deviation of 1.79%, against 2.96% for a global minimum and 5.39% for a plain median.
• A movement is only called significant when it clears the noise floor and no repetition's paired difference contradicts the direction, with a majority of repetitions positively agreeing. Base and head run interleaved within a repetition, so the pairs saw the same machine; a movement whose repetitions disagree is reported as unresolved rather than as a result. Runs shorter than 6 repetitions are never called significant — the floor is calibrated at that count and does not transfer below it.
• Base and head are driven one prove at a time, alternating, with the order flipped every prove. Running each side's batch back to back let the second side pay a consistent penalty — measured at +1.19% before this was fixed, which is a bias no number of repetitions removes.
• A wide gap between the reported figure and the max has two causes and the samples below do not separate them: interference within a repetition, and the proof-of-work grind differing between repetitions. Neither invalidates the comparison — both sides ran interleaved on the same machine — but a gap much wider than usual is worth a second look.
• Base and head are measured in the same job on the same runner, so runner-to-runner drift cancels out. The base dist may have been built by an earlier run of this workflow and restored from cache — the cache key covers the toolchain and the build commands, so the bytes match what this run would have produced.
• Δ % = (head − base) / base on that figure. Lower is better for every benchmark in this suite.
• Every figure above is recomputed here from the per-rep samples in the artifact; the summary statistics the bench script reported alongside them are not used.
• The ±1.90% threshold is calibrated on warp-ubuntu-latest-x64-8x (2026-08-27): 30 runs of one build against a copy of itself, at 6 repetitions, gave a standard deviation of 0.62% and a largest movement of 1.17%. It is 3σ (1.85%) rounded up, which here is the procedure rather than a deviation from it: the largest movement across those 30 no-change runs stayed below 3σ, so nothing observed argues the tail is heavier than normal. How this is measured.
• Full machine-readable results are attached to the run as results.json.

Per-rep samples

  prove / consume / ecdsa-k256-keccak
  base rep  1: 2,845.8, 2,853.0, 3,038.7
  base rep  2: 2,891.8, 3,112.2, 2,890.1
  base rep  3: 2,846.5, 2,869.4, 2,931.1
  base rep  4: 2,854.8, 3,067.7, 2,810.1
  base rep  5: 2,881.5, 2,845.0, 2,932.3
  base rep  6: 2,817.2, 2,813.5, 2,834.2
  base median 2,862.1 ms  min 2,810.1  max 3,112.2
  head rep  1: 2,895.5, 2,826.3, 2,915.7
  head rep  2: 2,888.3, 2,854.1, 3,045.9
  head rep  3: 2,868.7, 2,824.6, 2,862.4
  head rep  4: 2,959.4, 2,843.3, 2,857.4
  head rep  5: 2,851.6, 2,851.2, 2,830.2
  head rep  6: 2,811.8, 2,917.1, 2,900.7
  head median 2,859.9 ms  min 2,811.8  max 3,045.9

_{🔺 slower beyond the noise floor · 🔻 faster beyond the noise floor · ❔ no verdict — see the heading and notes above · ➖ within the noise floor}

---

_{Generated by bench run 35755881526 for 80f39fa. This comment is informational only and never blocks merge.}