fix(recovery): tell unreachable relays from empty ones, validate relay answers

[dmnyc]

Follow-up to #22, bringing data recovery up to the Lazarus spec's 0.6.2-draft (https://github.com/dmnyc/lazarus/blob/main/SPEC.md).

• Relay outcomes. Every relay request now ends as answered, failed, or timed out, and only an answered relay counts as having nothing. Each relay is asked directly: the shared subscription reports a relay that couldn't connect as finished, so a dead relay read as an empty answer, and a dead write relay could confirm the current version. Versions a relay sent before failing stay in the list. A scan no relay answered shows as an error instead of "no versions found", and nothing is recommended until one of your write relays has answered, since the newest version found may not be current.
• Authentication. A scan authenticates only to relays in your own relay list, so the archival and default relays never learn that the account itself is asking.
• Relay list. When the app has no relay list for the account, a direct lookup tells a missing list (the default relays stand in, and the page says so) from one that couldn't be fetched.
• Results show how many relays answered, with each relay's outcome on request.
• Pre-sign check. Only a newer version counts as a change, including one from the same second with a lower id (the one relays keep), and without an answer from a write relay the restore stops instead of assuming nothing changed.
• Scanned events count only with a valid signature, the scanned author, and the requested kind.
• Items are counted once each, a tag without a value isn't one, a profile's items are its fields (so a profile wiped to {} reads as empty), and relay URLs compare normalized.
• Private items. The review says which version's private items couldn't be decrypted. When it's your current version's, the restore replaces items nobody counted, so it takes the same separate confirmation as a restore that removes items, now a checkbox.
• Encryption key lists (kind 10044) count the n tags NIP-4e puts keys in; the registry counted p tags, so every key list scanned as empty. The review states what both versions mean, in the direction of the restore, and asks you to confirm the change.
• Publish succeeds when one write relay accepts the restore. The shared publish waited for a third of the relays, so a restore that had gone out could be reported as failed.
• Profile changes cover every field and tag a restore would replace, not a fixed list.