mock.module in load-meta.test.ts leaks into other test files

Discovered while adding tests in #286.

`src/commands/load-meta.test.ts` installs `mock.module("../core/client.ts", …)` and `mock.module("../core/metadata.ts", …)`. Bun's module mocks are process-global and are never restored, so every test file that evaluates after it in the same run (alphabetically later, e.g. `tx-eth.test.ts`, `tx.test.ts`) silently gets the mocked `createChainClient` / `fetchMetadataFromChain` — i.e. the polkadot fixture metadata for any chain name, and no real network.

Observed effect: an in-process test connecting to previewnet failed deterministically in full-suite runs with "Chain "preview-asset-hub" does not expose pallet-revive" in ~15ms (fixture metadata served instead of a connection), while passing standalone. In #286 the affected test was converted to a subprocess `runCli` test to sidestep the leak (commit 8d7f574) — at the cost of coverage instrumentation.

Possible fixes: isolate load-meta tests behind dependency injection instead of `mock.module`, or run them in a dedicated process (bun `--preload` per-file isolation), or restore the real modules in `afterAll` by re-mocking with the captured originals. Until then: any in-process test that needs real chain connectivity must live in a file that sorts alphabetically before `load-meta.test.ts`, or run as a subprocess.

Start with src/commands/load-meta.test.ts and reproduce the full-suite ordering issue involving tx-eth.test.ts and tx.test.ts. Trace how Bun's mock.module calls persist between files, then verify that real chain connectivity is restored for later in-process tests without losing the intended load-meta coverage.