Harden Nostr mesh discovery

[i386]

Summary

Clients now recover when Nostr discovery returns malformed mesh listings or bad invite tokens instead of failing the whole auto-join flow.

What Changed

• validate discovered Nostr listings before ranking or attempting joins
• reject malformed invite tokens and other obviously broken listing data early
• skip invalid mesh candidates during auto-join and Nostr re-discovery instead of aborting
• log warnings when bad Nostr data is encountered
• add invite-token round-trip and invalid-token tests

Root Cause

Nostr listing content was being treated as trustworthy enough to defer validation until join time. A malformed invite_token could survive discovery, get selected as a candidate, and then fail with a JSON parse error or force the client into a bad fallback path.

Impact

• malformed or malicious Nostr publishes no longer poison mesh discovery as easily
• clients continue trying other meshes when a candidate's token is invalid
• logs now make it clearer when the failure is bad Nostr data versus a live peer handshake failure

Validation

• cargo fmt --all -- mesh-llm/src/network/nostr.rs mesh-llm/src/mesh/mod.rs mesh-llm/src/mesh/tests.rs mesh-llm/src/runtime/mod.rs mesh-llm/src/runtime/discovery.rs
• manual run: /Users/jdumay/.local/bin/mesh-llm client --auto --port 19337 --console 13131
• just build is in progress to restore local UI assets for full repo validation
• cargo check -p mesh-llm was previously blocked because mesh-llm/ui/dist was missing in this worktree

[michaelneale]

Review

Good change — validates Nostr listings before joining and falls back through candidates instead of committing to a single token. The validation, typed errors, and tests are solid.

Issues

1. run_auto join loop inconsistency. The PR adds candidate fallback (try #2 if #1 fails) in join_mesh_for_mcp and the client --auto path in run(), but the run_auto join loop (~line 1340) only got the better error message — not the full fallback-through-candidates behavior. All three join paths should be consistent.

2. discovered_mesh() test helper uses raw "published-token" which would fail validate_listing. Fine for the current unit tests but a latent footgun — should use valid_invite_token() like the scoring tests do.

3. client_count > max_clients * 8 heuristic is undocumented. Why 8x? And max_clients: 0 skips the check entirely, so a listing with max_clients: 0, client_count: 999999 passes validation — could that game scoring?

4. No test for the actual fallback behavior — tests confirm queue_auto_join_candidates populates the list, but nothing tests that when candidate #1 has a bad token, candidate #2 is actually tried.

5. valid_invite_token takes an unused _label: &str param — can just be valid_invite_token().

[michaelneale]

I think can close this one now?