[iOS][Mobile] Returning from background can leave conversation composer unable to open keyboard

## Client / platform
- Client: Cindy mobile app
- Platform: iOS, reported on iOS 27
- Frequency: intermittent; not reproduced 100% of the time
- App/build version: not yet captured

## Problem
After leaving Cindy and returning to the current conversation, the conversation composer can intermittently stop accepting focus. Tapping the input area has no visible effect and the iOS software keyboard does not appear. The issue can occur after a short time away from the app; a long background period is not required.

## Reproduction path
1. Open an existing conversation in Cindy mobile.
2. Leave Cindy for another app.
3. Return to the same conversation.
4. Tap the conversation composer and check whether the keyboard appears.

## Potential trigger variables
The issue is intermittent, so test these combinations separately:
- Switch to another app, take a screenshot, and save it before returning.
- Tap a link in a Cindy message to open the external browser, then return to Cindy.
- Return while the current Agent task is still running versus after it has completed.
- Short background interval versus longer interval.

Please add temporary diagnostics or a focused reproduction harness if needed. Record AppState transitions, WebView lifecycle/visibility, editor focus/blur events, touch events, keyboard show/hide events, and the composer editable/hidden state.

## Expected behavior
After returning from another app or the external browser, tapping the visible conversation composer focuses the editor and presents the iOS keyboard.

## Actual behavior
Intermittently, tapping the composer does nothing: the editor does not visibly focus and the iOS keyboard does not appear. The composer may become usable again only after leaving the conversation and re-entering it.

## Root-cause analysis
The likely failure area is iOS WKWebView/contentEditable focus recovery after app or browser background/foreground transitions. The current mobile composer is implemented as a WKWebView contentEditable editor rather than a native React Native text input.

Relevant code locations:
- `apps/mobile/src/session/ComposerRichInput.tsx:78-141`: stores the WebView ref and sends `window.cindyComposer.focus()` through injected JavaScript.
- `apps/mobile/src/session/ComposerRichInput.tsx:365-390`: configures the WebView, including `keyboardDisplayRequiresUserAction={false}`, but has no explicit AppState resume focus reconciliation.
- `apps/mobile/src/session/composerRichInputHtml.ts:52-60`: defines the editable `#editor`; ordinary taps rely on WebKit default focus behavior.
- `apps/mobile/src/session/composerRichInputHtml.ts:457-463`: explicitly handles touch only for `.atom` reference chips; there is no general post-resume tap/touchend focus fallback.
- `apps/mobile/src/session/composerRichInputHtml.ts:229-243`: focuses the editor only through the explicit caret-placement path.

This is a hypothesis, not a confirmed root cause. Diagnostics should distinguish WebView focus loss, touch delivery failure, hidden/overlay hit-testing, and an `editable` state regression.

## Suspected fix direction
- Add iOS AppState foreground/resume diagnostics and focus-state reconciliation for the visible composer.
- Add a user-initiated tap fallback that explicitly focuses the editor while preserving selection, reference chips, paste, scrolling, and voice-input behavior.
- Do not make unconditional WebView reload/remount the first-line fix unless draft content, selection, and pending paste state are preserved.
- Add regression coverage for app switch and external-browser return paths where the test environment permits.

## Risk notes
- The composer supports rich content, reference chips, paste handling, voice input, and dynamic height; focus recovery must not discard drafts or alter selection.
- Scope the change to iOS/WebView resume behavior and avoid changing Android behavior.

## Acceptance criteria
- On iOS 27, after returning from another app, tapping the current conversation composer consistently opens the keyboard and permits text entry.
- Verify the external-browser path: Cindy message link → browser → Cindy → tap composer.
- Verify return while an Agent task is running and after the task has completed.
- Verify both short and longer background intervals.
- Existing draft text, reference chips, paste behavior, voice-input behavior, and composer height remain intact.
- Add diagnostics or tests sufficient to identify the failure mode if the issue cannot be reproduced deterministically.

Start with apps/mobile/src/session/ComposerRichInput.tsx:78-141 and :365-390, then inspect the editor and touch handling in composerRichInputHtml.ts:52-60, :229-243, and :457-463. Reproduce the listed app-switch and browser-return paths while recording the specified AppState, WebView, focus, touch, keyboard, and editable-state diagnostics. Done means iOS resume taps reliably open the keyboard without affecting drafts, chips, paste, voice input, selection, or composer height.

Written by the indexing model from the issue text.