Desktop: STACK_OVERFLOW crash (0xc00000fd) on Windows — two distinct offsets, related to ACP install / unnamed roster member retry

## Summary

Buzz Desktop crashes with `STACK_OVERFLOW` (Windows exception `0xc00000fd`) on Windows 10, reproduced with two distinct fault offsets across two different builds. Built locally from source (not the official release) via `pnpm tauri build --features mesh-llm --target x86_64-pc-windows-msvc`.

## Environment

- OS: Windows 10 Pro 10.0.19045
- Backend: local self-hosted relay (`just relay`), Docker-based dev stack (Postgres/Redis/MinIO/Keycloak)
- Build: from source, NSIS installer

## Crash 1 — commit `3c7f288` (2026-09-05)

- **Exception:** `0xc00000fd` (STACK_OVERFLOW)
- **Fault offset:** `0x6138e87`
- Reproduced 3 times with two different triggers on the same offset:
1. Onboarding → "Set up your agent harnesses" → clicking **INSTALL** next to Claude Code (installing the ACP adapter for an already-detected `claude` CLI on PATH).
2. Clicking **Retry** on a channel's message list, after adding a second identity (an agent, via `buzz channels join` over the CLI) as a channel member — that identity has no `display_name` set (shows as "unnamed" in the roster).

Since the same offset was hit by two seemingly unrelated UI actions, the bug is likely in shared code (error/retry handling, or roster/member rendering) rather than being specific to either feature.

## Crash 2 — commit `7861880` (2026-09-11, current `main`)

After pulling latest `main` (26 commits ahead of `3c7f288`, including `fix(desktop): order unnamed roster members by full canonical npub` #7503, which looked directly relevant) and rebuilding, **Crash 1 no longer reproduces** — but a new, different crash appeared:

- **Exception:** `0xc00000fd` (STACK_OVERFLOW)
- **Fault offset:** `0x69259e7`
- **Trigger:** same as Crash 1's second trigger — clicking **Retry** on a channel's message list after an unnamed (no `display_name`) agent identity was added as a channel member via the CLI.

## Reproduction steps (Crash 2, current main)

1. Fresh local relay + Postgres, one human identity (owner) with a completed profile.
2. Add a second identity to a channel via CLI: `buzz channels join --channel ` using a private key that has no profile/`display_name` set (i.e. a bare agent identity, never went through desktop onboarding).
3. Open that channel in Buzz Desktop as the human identity. Message history fails to load (`Couldn't load messages`).
4. Click **Retry**.
5. App crashes immediately (`STACK_OVERFLOW`).

## Additional finding (may or may not be related)

While diagnosing why the CLI-sent message from the unnamed agent identity wasn't visible in the desktop client's history at all (separate from the crash): the relay accepts writes from a pubkey that isn't in `channel_members`, but apparently doesn't surface that message's history to other clients until the sender is added as an actual member (`buzz channels join`). Not sure if this is intended defensive behavior or a gap — flagging in case it's relevant context for the crash (rendering a message from a previously-unknown/unnamed member for the first time).

Happy to provide Windows Event Log XML, more detailed repro data, or test a patched build if useful.

Reproduce the crash on current main with `pnpm tauri build --features mesh-llm --target x86_64-pc-windows-msvc`, `just relay`, and an unnamed member added by `buzz channels join`. Trace the Desktop Retry flow, message-history loading, roster/member rendering, and ACP install path implicated by the two triggers. Done means Retry no longer causes the Windows stack overflow and the affected channel history and unnamed member are handled without crashing.

Written by the indexing model from the issue text.