fix(desktop): harden relay mesh connect p-tag

[tlongwell-block]

Summary

Defense-in-depth for relay-mesh connect requests + the desktop e2e harness. Hardens the create-agent → Run on relay mesh path so a malformed reporter pubkey fails locally with a clear error instead of producing an opaque relay rejection downstream:

• canonicalize the selected mesh target reporter pubkey before signing kind 24621 (trim → lowercase → require canonical 64-hex; otherwise throw a clear invalid-reporter-pubkey error locally)
• make the e2e WebSocket bridge reject mock kind 24621 connect requests missing a #p target instead of blindly ACKing them
• Playwright coverage that Create Agent → Run on relay mesh signs a kind 24621 with canonical ["p", <64-hex>], including an uppercase/whitespace reporter-pubkey regression case

What this is and is NOT

Is: correct, verified hardening of the one create-path publisher + a real regression guard.

Is NOT (and we are explicit about this): a confirmed fix for the live report —

Mesh client failed to start: invalid: mesh connect request missing #p target

Joint trace (Eva + Max) findings, now reconciled:

• "invalid: mesh connect request missing #p target" exists in exactly one place — sprout-relay/src/handlers/mesh_signaling.rs. It fires only when an incoming 24621 carries zero ["p", <nonempty>].
• The only Sprout-24621 publisher in the desktop tree is TS publishMeshConnectRequest, reachable through exactly one chain: CreateAgentDialog → startRelayMeshClientForTarget → publishMeshConnectRequest (exhaustively enumerated; no restore/auto-start hook touches it).
• That publisher already attaches ["p", targetPubkey], and startRelayMeshClientForTarget guards an empty reporterPubkey with a different error. Against the relay's actual nostr dep, a non-canonical p-tag value (uppercase/whitespace/npub) is preserved, so it would surface as a membership/identity error, not "missing #p".
• The mesh SDK does not publish a Sprout 24621 at all (it gossips kind 31990 listings to public relays). So the Rust agent-start/restore path cannot be the direct source of this exact relay string.

Net: current main should not be able to emit "missing #p" on any traced path. The live repro therefore implies either a build predating these guards, or a publisher not yet found — pending the raw outbound 24621.tags frame or the failing build SHA.

Known structural gap (separate follow-up, not this PR)

Saved relay-mesh agents on restore/manual-start resolve a target by model_id and then discard everything but endpoint_addr. Reconnecting cleanly needs a target Nostr identity:

• own-machine target → no relay punch at all; dial locally (relay rejects self-#p anyway).
• peer target → no peer Nostr pubkey is carried in mesh status today (PeerInfo/PeerAnnouncement are iroh-addressed + owner_id, not Sprout pubkeys). Near-term: fail with actionable copy. Full fix: protocol work to carry a per-target Nostr pubkey in relay status.

A containment patch for the targetless cold-start path exists (Max) and is parked pending the evidence above, so we don't ship behavior changes against an unconfirmed mechanism.

Test plan

• bin/pnpm --dir desktop exec biome check src/shared/api/relayMeshSignaling.ts src/testing/e2eBridge.ts tests/e2e/mesh-compute.spec.ts tests/helpers/bridge.ts ✅
• bin/pnpm --dir desktop typecheck ✅
• bin/pnpm --dir desktop check:file-sizes ✅
• bin/pnpm --dir desktop test:e2e:integration -- mesh-compute.spec.ts ✅ 5/5
• pre-commit / pre-push hooks ✅ (run with repo bin/ first on PATH to use Hermit Rust)