v0.5.8: mn test and localnet fixes, and the MCP skill resource ships

📦 npm: https://www.npmjs.com/package/midnight-wallet-cli/v/0.5.8 (npm i -g midnight-wallet-cli@0.5.8)

Fixed

• The MCP server's core skill resource can be read from an installed package. midnight-wallet://skill/core is the first document an agent is pointed at, and reading it failed with ENOENT ... docs/SKILL-CORE.md: the file was missing from the published package (every 0.5.x release since the skill was split in two). It ships now, and the fresh-install check in CI reads every resource the installed MCP server lists.
• The skill document no longer points agents at tools that do not exist. Two error recipes said to call midnight_status(), and the testing section said to run suites with midnight_test_run; neither is a tool of this line. The recipes name midnight_localnet_status() and what to do on a hosted network, and the testing section says mn test run is a CLI command. The fresh-install check now compares every tool call the skill documents show with the tools the installed server lists.
• A failed mn test run exits 1. It printed FAIL and exited 0, so a failing suite passed in CI. (Every wallet command ended with exit(0) whatever exit code the command had set.)
• mn test run passes the first time on a new chain. The dust prep step ended as soon as the wallet had any Dust, and the suite's deploy, a moment later, failed with "Insufficient Funds: could not balance dust"; a second run passed. The step now waits for the amount mn asks for before any transaction (0.8 DUST, about a minute and a half for the 1000 NIGHT the prep funds), and says how much there is while it waits. A CLI suite waits for the same amount before each deploy and call, since each fee leaves the wallet short until its Dust regrows: a call sent the moment a deploy landed failed the same way.
• mn test run no longer needs curl. Its localnet-up step probed the indexer by shelling out to curl. Where there is none (a slim container image, a CI runner) it decided a healthy localnet was broken, tore it down twice, and failed with "Localnet failed to start after 2 attempts". It asks over HTTP from Node now. The waits in mn localnet up no longer shell out to sleep either, which Windows does not have.
• A suite does not reuse a contract from a chain that is gone. mn test run keeps the address it deployed at, to reuse the contract on the next run. After mn localnet down and up that address is on no chain, and the run failed with "No contract found at address ...". Before reusing the address the suite now asks the indexer whether a contract is there, and deploys again when there is none. (A new local network has the same genesis hash as the last, so nothing short of asking can tell them apart.)
• mn test results shows results. It read the runner's own .contract-cache-<suite>.json in the results directory as the latest result, printed undefined — FAIL (undefineds) and crashed.
• Adding a browser suite to a project that has a CLI suite gives a suite that can run. mn test create --strategy ui left an existing dapp.test.json as it was, without the port, the build command or the build-and-serve step the new suite needs. Whichever of those the file lacks are added; everything already in it is kept.
• mn localnet up explains the failures a user can fix. A port held by another container ("port is already allocated") got Docker's raw message; only a port held by a program on the host was explained. Both are now, naming the port. A Docker daemon that is not running is said to be that.
• mn localnet status shows a stopped localnet as stopped. After mn localnet stop it reported no services, the same as after down.

Changed

• mn says when a long Dust sync is not using the native reader. Without the dust-sync sidecar a first Dust sync runs through the built-in WASM reader, several times slower, and nothing said so unless --verbose was on. On a sync of more than 50,000 events mn now prints one line on stderr with the reason: Native Dust reader not installed (@nel349/dust-sync-linux-x64): reading with the built-in one, several times slower on a long sync. The reasons are not installed (npm ran with --omit=optional, or no build for the platform), can't start on this system (Alpine and other musl Linux, where the glibc binary installs but cannot run), disabled by MN_DISABLE_NATIVE_DUST=1, and failed. A short sync says nothing.
• mn test run output: one mark per line, and the error, not a stack. Prep steps and actions printed two marks (✓ ✗ deploy: ...), and a failed deploy or call printed the generated script's whole stderr, Node stack included; mn contract deploy and call did the same. The line is now the error itself ("Insufficient Funds: could not balance dust"). A browser suite run without the Claude Code CLI says that is what it needs.
• --verbose names the reader on every Dust sync: dust: native sidecar: <path>, or dust: native sidecar <reason>, using WASM.
• Docs: how long a first sync takes, and what the native reader needs. The README, mn manual, mn help --agent and both MCP skill documents give the measured times of a wallet's first Dust sync with 0.5.7 installed from npm (preprod, 1.6M events: about 5 minutes native; preview, 144k events: about 30 seconds native against about 2 minutes in WASM; seconds after that), say which commands trigger it, which platforms the sidecar is built for (macOS arm64 and x64, Linux x64 and arm64 on glibc, Windows x64), how to tell which reader ran, and how to get the native one back.

---

Package on npm: https://www.npmjs.com/package/midnight-wallet-cli

Full changelog: https://github.com/nel349/midnight-wallet-cli/blob/main/CHANGELOG.md