THREAD: custom-provider upstream errors are mislabeled as channel-access failures

**THREAD context**

This happens in Buzz's THREAD / agent turn transcript surface when an agent uses a custom model provider. The provider or gateway returns an upstream error, but THREAD presents it as if the model/agent does not have access to the channel.

**Describe the bug**

The THREAD error-normalization path treats JSON-RPC code `-32001` as community/channel access denial unconditionally. A custom provider can return that code alongside an actionable upstream gateway/model response, but the UI replaces that response with:

> Community access denied this agent — check its community membership.

That message is deceptive when channel membership is valid. The real upstream response is only visible by opening the tool-call or runtime log, which makes provider debugging unnecessarily difficult.

**Steps to reproduce**

1. Configure an agent to use a custom provider/model.
2. Start an agent turn from a channel so it appears in THREAD.
3. Have the provider or gateway return an upstream failure represented with code `-32001` and a meaningful normalized error body.
4. Open the turn in THREAD.
5. Observe that THREAD reports a community/channel access problem instead of the upstream provider response.

**Expected behavior**

THREAD should show the normalized, safely redacted upstream provider error when the failure originated from the provider/gateway. Channel-access wording should be reserved for failures carrying explicit channel/community authorization evidence, rather than inferred from the numeric code alone.

**Version and platform**

- Buzz version: unknown
- OS: unknown

**File references / additional context**

- [`friendlyAgentLastError.ts`](https://github.com/block/buzz/blob/2ea9385015fb922de2adf0a53e86fc5a21d07b90/desktop/src/features/agents/lib/friendlyAgentLastError.ts#L72-L104) maps every `-32001` to `RELAY_MESH_DENIED_COPY` before considering the upstream message.
- [`agentSessionTranscript.ts`](https://github.com/block/buzz/blob/2ea9385015fb922de2adf0a53e86fc5a21d07b90/desktop/src/features/agents/ui/agentSessionTranscript.ts#L772-L784) applies that normalization to THREAD `turn_error` and `agent_panic` entries.
- The error pipeline documentation in [`friendlyAgentLastError.ts`](https://github.com/block/buzz/blob/2ea9385015fb922de2adf0a53e86fc5a21d07b90/desktop/src/features/agents/lib/friendlyAgentLastError.ts#L1-L29) says generic harness errors should retain their text, but the `-32001` branch currently discards it.

No credentials, provider secrets, or unredacted upstream payloads should be included in the display or logs.

Start with the error-normalization documentation and the -32001 branch in desktop/src/features/agents/lib/friendlyAgentLastError.ts, then trace how desktop/src/features/agents/ui/agentSessionTranscript.ts applies it to turn_error and agent_panic entries. Verify the behavior with the custom-provider reproduction described in the issue. Done means explicit channel or community authorization failures retain the access-denied wording, while provider or gateway failures display their safely redacted normalized response.

Written by the indexing model from the issue text.