fix(desktop): encode resolved mentions as NIP-27 Nostr URIs

[fresh3nough]

Summary

• Rewrite resolved @name mentions to stable NIP-27 nostr:npub1… URIs on send and edit so profile renames cannot break historical mentions
• Keep recipient/p tags for notification and routing; encoding only changes the prose body
• Materialize inbound nostr:npub1… and nostr:nprofile1… prose into the existing mention chips using current profile identity, including references that arrive without a recipient tag
• Protect code spans/blocks, Markdown link destinations, emails, escaped @, and non-profile NIP-21 entities from rewrite; longest complete name wins on overlap; conversion is idempotent

Fixes #2319

Why this PR

Open #2503 also touches NIP-27, but bundles it with unrelated community-create and workflow-query fixes and leaves important remainder work:

• no inbound nprofile support
• display mapping depends on already-known tag-derived name maps instead of hydrating body-only profile refs
• weaker Markdown protection surface (mainly code masking)

This PR is scoped solely to #2319 and covers the full encode + display path on current main.

Test plan

• Send a message with a resolved @name mention and confirm the published event body contains nostr:npub1… while the composer still showed @name
• Edit a message that adds a mention and confirm the edit body is NIP-27 encoded and only newly added mentions produce notification tags
• Receive/display a foreign event with nostr:npub1… and no p tag; confirm it renders as a clickable mention chip with the current profile name
• Receive/display nostr:nprofile1… (with relay hints) the same way
• Confirm inline/fenced code, link destinations, emails, escaped \@, and non-profile nostr: entities are left unchanged
• Confirm overlapping multi-word names pick the longest match and re-encoding an already-encoded body is a no-op