Support NIP-24 website and banner profile metadata in desktop

## Problem

Buzz Desktop currently models and displays only part of a kind:0 profile. The standard NIP-24 `website` and `banner` fields are not exposed in Profile settings or rendered in the member profile panel.

That leaves profiles less useful for community members who want to share a primary website and visually distinguish their identity without introducing a Buzz-specific metadata format.

## Proposed scope

Add first-class Desktop support for the standard NIP-24 fields:

- parse `website` and `banner` from kind:0 metadata
- allow users to edit their website in Profile settings
- allow users to upload, replace, and remove a banner using the existing media-upload path
- render the banner and website in the existing member profile panel
- accept only valid HTTP/HTTPS URLs, reject embedded credentials, and fall back cleanly when a banner cannot load
- preserve existing avatar, profile-cache, deferred-avatar, and profile animation behavior

This would remain within the existing kind:0 profile, Tauri profile command, media upload, and profile UI architecture. It would not add a dependency, endpoint, event kind, or parallel profile model.

## Relationship to existing profile-preservation work

This feature should integrate with the resolution of #2534 rather than silently rebuilding a new fixed allowlist.

Two open PRs currently address preservation of unmodeled kind:0 fields:

- #2606
- #3294

The implementation should be rebased onto whichever preservation approach maintainers select so profile edits retain `bot`, `lud16`, future NIP fields, and other unmodeled metadata.

## Explicitly out of scope

- custom social-link arrays or provider-specific metadata
- banner positioning/cropping metadata
- joined dates or community-role changes
- CLI profile flags
- mobile profile editing
- unrelated profile refactors

Those can be discussed separately after the standard fields are supported.

## Acceptance criteria

- existing NIP-24 website/banner metadata is parsed and displayed
- website edits and banner upload/removal round-trip through kind:0
- unsafe website schemes are rejected
- unavailable banner images do not break the profile panel
- existing profile fields and unmodeled kind:0 metadata remain intact
- existing profile tests remain green, with focused Rust, frontend, and Desktop E2E coverage added

Is this focused Desktop scope acceptable once the #2534 preservation work is resolved?

First review #2534 and the selected preservation approach, including how it affects the existing kind:0 profile model. Then inspect the Tauri profile command, media-upload path, and member profile UI. Run the existing profile tests and add focused Rust, frontend, and Desktop E2E coverage; done means website and banner round-trip safely while existing and unmodeled metadata remain intact.

Written by the indexing model from the issue text.