Desktop: thread composer can lose focus; typing is ignored and Backspace closes the thread

**Describe the bug**

In an open message thread, the composer stopped accepting keyboard input. Ordinary character keys produced no text. Pressing Backspace closed the thread instead of deleting text.

The desktop process and renderer were both still alive. macOS Accessibility inspection showed focus on the webview (`AXWebArea`) rather than the composer (`AXTextArea`).

**Steps to reproduce**

The exact trigger is not yet isolated.

Observed sequence:

1. Leave Buzz Desktop running with channels and threads in normal use.
2. Open a message thread.
3. Attempt to type in the thread composer.
4. No text appears.
5. Press Backspace.
6. The thread closes.

The affected renderer had been running continuously since the previous day.

**Expected behavior**

Opening a thread should leave its composer focused and ready for text input. Backspace should edit the composer and must not fall through to thread/browser navigation.

**Version and platform**

- Buzz version: 0.5.19
- OS: macOS 26.5.2 (25F84), Apple Silicon (`arm64`)

**Logs / additional context**

Confirmed observations:

- Before recovery, the focused accessibility element was missing or `AXWebArea`, not `AXTextArea`.
- Five non-empty drafts were present in WebKit local storage.
- Terminating only Buzz's WebKit renderer caused the desktop process to spawn a new renderer.
- The main `buzz-desktop` process and managed agents remained running.
- All five drafts survived.
- After the renderer recycled, the focused element was `AXTextArea` and typing was restored.
- No matching open or closed issue was found. #3775 concerns the opposite state: navigation shortcuts being swallowed when the composer already has focus.

**Suspected code path (not proven)**

[`useComposerAutofocus`](https://github.com/block/buzz/blob/desktop-v0.5.19/desktop/src/features/messages/lib/useComposerAutofocus.ts) reads `disabled` through a ref but intentionally excludes it from the effect dependencies. If the thread composer mounts while transiently disabled, the effect returns and does not retry when the composer becomes writable. That appears capable of leaving focus on the webview, matching the observed state.

A regression test could mount the thread composer disabled, transition it to enabled, and assert that the editor eventually receives focus.

Start with desktop/src/features/messages/lib/useComposerAutofocus.ts and inspect how the disabled ref and effect dependencies handle a composer that mounts disabled. Add a regression test that transitions the thread composer to enabled and asserts the editor receives focus. Done means the composer regains focus for typing and Backspace does not close the thread.

Written by the indexing model from the issue text.