docs: fixes from an end-to-end dogfooding run of every runnable doc

[weboko]

Fixes found by running the runnable docs end to end on a Linux host, as a new user would. Every change is backed by an actual run.

What was executed this pass

Basecamp 0.2.3 driven on a virtual display (package install → Settings → Module Inspector → load); the ETH↔LEZ swap app upgraded to 0.4.6 and taken through catalogue → setup → LEZ activation → live market; the LEZ wallet CLI against the public testnet (init, Piñata claim, transfer, balances); a Logos Blockchain node from the CLI (install → module → config → start → peers → faucet); a storage node (uploaded a file, downloaded Farewell to Westphalia — checksum matched the doc exactly); a six-node Mix network (upload via node 5, download via node 6, SURB path confirmed in the log); a delivery node (live ENR); and a core module built from the template, packaged and called via logoscore.

Repo-wide checks: docusaurus build passes with onBrokenLinks: throw, Vale is clean on all changed files, all 80 referenced GitHub repos resolve, every logos-module-builder pin and template name exists, and all image references resolve.

Fixes in this PR

Doc	Problem
blockchain/zone-sdk/inscribe-data-on-chain-using-zone-sdk	Step 1 was unfollowable. cd logos-blockchain/deployment/tui-zone straight after cloning fails — that directory exists only on the tui-zone-tutorial branch. Reproduced on a real clone. The demo link (tree/master/…) 404s and the claim that master holds a fuller implementation is false: master has no tui-zone at all.
basecamp/swap-eth-and-lez-tokens-…	Toolbar button is Manage Repositories, not "Repositories". Installing opens Install Package?, not an "Add Application" window listing "Required Packages". The offer pane has no Hashlock row (the hashlock derives from the preimage the buyer's app invents on accept, so it cannot exist before the offer is taken), which also made the Step 5 comparison impossible. The disabled Accept button explains itself above the button, and the usual reason — an unfunded ETH address — was not among the listed messages.
messaging/get-started/send-1-1-messages-logos-chat	Option B pinned v0.1.0, the oldest tag in logos-chatsdk-ui and older than every published release, while Option A installs 0.2.2 from the catalogue — the two options ran different apps, and v0.1.0 predates the address-based flow Step 2 describes.
blockchain/get-started/run-a-logos-blockchain-node-from-cli	Added the restart case: against an existing state directory, start returns METHOD_FAILED/RPC_FAILED while the node actually comes up and syncs (reproduced twice). The existing troubleshooting entry blames an unreachable daemon or unloaded module, neither of which applies. Also noted /cryptarchia/info returning 408 under sync load while /network/info answers.
lez/transfer-tokens/transfer-native-tokens-…	wallet account new public prints the account ID and its public key, not the ID alone.
lez/programs/write-and-deploy-lez-program-with-scaffold	The localnet is fixed to port 3040 and the doc never says so. Worse, [localnet].port in scaffold.toml looks like a workaround but isn't: scaffold writes it into sequencer_config.json and polls it, while the sequencer binary still binds its --port default of 3040 and wallet_config.json keeps pointing at 3040 — so deploy and wallet topup silently talk to whatever else is on 3040 and report success. Added a warning telling readers to free the port instead.
storage/…/run-logos-storage-node, …/run-mix-network-of-storage-nodes	The lgpm list sample output printed (v) in the VERSION column of a block shown as literal terminal output; the real output prints 2.1.2, the very version the step above pins.
peer-discovery/…/build-logos-core-module-that-uses-service-discovery-api	Seven defects; five of them block a reader outright. The vendor step promises to copy the C-binding header and shared library into ./lib, but find /nix/store -name libp2p.so -path '*cbind*' matches nothing — the derivation ships liblibp2p.so, so the library was silently skipped (find exits 0 either way). The build line targets example_service_discovery, which does not exist: cmake fails with No rule to make target; the real target is tutorial_9_service_discovery, and it lands in build/tutorial/, not build/examples/. And the expected-output block described an older program entirely — demo-service, 16Uiu2HAk… peer IDs, "matched the advertiser", "Signed XPR is 288 bytes", "Done". The tutorial's own C++ then fails to compile — it calls discoStartAdvertising(serviceId, serviceData) while the generated API takes three arguments (upstream passes ""), and the inline comment "requires BOTH" reinforced the wrong arity. Step 3 builds with .#install, which emits a linux-amd64-dev variant that the released logoscore from this doc's own prerequisites refuses (MODULE_LOAD_FAILED); .#install-portable is the loadable one. Finally the Step 5 result shows "data":"version=1" where the field is actually base64 (dmVyc2lvbj0x). All corrected against a real build, and the full three-node DHT discovery now runs: the discoverer finds the advertiser on port 9001 knowing only the bootstrap node.
lez/transfer-tokens/create-and-transfer-custom-tokens-…	Step 2 never says how a recipient becomes a token holder. wallet token send to a fresh public account is silently discarded — hash printed, Transaction is None, sender unchanged, recipient still Uninitialized. Verified the alternatives: auth-transfer init hands the account to the wrong program and the send still fails, and token mint to a fresh account is discarded too, while minting to the --supply-account-id holder works (1337 → 1837). Added a warning explaining that a public holding account only ever comes from token creation.
blockchain/node-app/build-and-run-logos-blockchain-node-app-ui	The curl /cryptarchia/info sample showed the flat mode object — that is the logoscore call shape; the HTTP endpoint nests under cryptarchia_info with state plus a top-level phase. Also, the release notes contain no "testnet bootstrap peers" string to search for; the peers sit under Initialize Your Node.
core/…/wrap-a-c-library-as-a-logos-core-module	The lm metadata expected-output block was missing the Display name and Protocol lines the tool actually prints.
lez/get-started/run-lez-wallet-via-cli	Added the libpcsclite-dev / pcsc-lite-devel prerequisite (the wallet pulls pcsc-sys, whose build script fails without it) and generalised the poller note: init, pinata claim and send all print Error: All pollers failed and exit non-zero on transactions that settle fine.

Plus three small corrections: wallet account new private-accounts-key prints the key node's path (e.g. /1), not a chain_index as the private-transfer page claimed; the Basecamp node page labelled its peer example "release 0.2.2" while Step 1 installs 0.2.3 (the addresses are identical in both releases' notes), and a missing space before a code span rendered as overrideflake.nix in the peer-discovery tutorial.

Earlier commits on this branch (module versions and root hashes, logoscore config key paths, absolute data-dir, Basecamp Module Inspector wording, module-info, LGX variant guidance) were re-verified against live systems this pass rather than taken on trust.

Software issues for the owning teams — not doc bugs

1. LEZ wallet exits non-zero on transactions that succeed. auth-transfer send prints the hash then Error: All pollers failed (exit 1), while the transfer settles — verified 113→106 / 37→44 with the tx on chain. Any script checking exit status sees a good transfer as failed.
2. blockchain_module start reports failure on a node that starts fine (see the doc row above). The documented happy path reads as a hard failure on any restart.
3. /cryptarchia/info returns HTTP 408 under sync load while /network/info returns 200 — this is the endpoint the tutorial tells operators to poll.
4. lgpm 0.2.1 rejects packages from the tutorial-v1 builder — .#lgx emits a manifest with no hashes block: Package validation failed: Missing content hashes in manifest. Reproduced; the doc's preferred packaging path is unusable with the tools its own prerequisites install, and the nix bundle workaround is documented in the meantime.
5. rzup install r0vm fails behind a TLS-inspecting proxy with InvalidCertificate(UnknownIssuer) against api.github.com, where curl/git to the same host succeed.
6. logos-scaffold 0.3.0 only partly honours [localnet].port, causing silent cross-talk. With port = 3055 set, localnet start still failed against the process on 3040; starting the sequencer by hand on 3055 left its log completely empty while deploy (5/5 "submitted") and wallet topup both reported success — they had gone to an unrelated sequencer on 3040. On any shared machine a developer's deploys and faucet claims are submitted to someone else's sequencer and reported as successful.

Correction to an earlier claim on this PR: the blockchain faucet backend is not auth-gated. POST /web/faucet-backend/<key> returns 202 {"status":"queued"} today, exactly as documented.

Not covered

Run on a shared host with ~1-3 GB of free RAM, which bounds a few things. The risc0 proving path (private/shielded LEZ transfers, the AMM trade) OOMs — the public paths are all verified. The full swap trade needs real Sepolia ETH from a browser PoW faucet. Docker-based flows (the LEZ indexer's local stack) cannot run: no CAP_SYS_ADMIN. Anything needing a fully-synced Online blockchain node (the faucet balance check, joining Blend as a core node) needs ~1h of sync that restarts lose.

Where a GUI step could not be driven I have said so rather than implied coverage: the C++ UI module builds and launches, but clicking Add in its view was not exercised (nix run OOM-killed); the delivery API module builds, but its two-instance messaging run was not; and the chat and mixnet docs' two-instance message exchanges were not.

Thirty of the seventy pages are prose-only — verified by scan to contain no shell blocks and no command lines — so the repo-wide checks above are the meaningful verification for them.

[kashepavadan]

@weboko Thanks for this! Any way we can get a check like this to run once in a while, like once a month or something?

[weboko]

@kashepavadan I put it to be run once a month

[weboko]

@kashepavadan @cheny0 can you review? I clarified some items but still would like someone else to take a look as I am not sure in some parts

alternatively, maybe, should I split this PR in couple? pre doc package?