fix: auto-open the keyboard when launching into a chat, without fighting Back

[gsxdsm]

What

When Auto-open keyboard is enabled, opening a conversation directly — from a notification/URI, a launcher shortcut, or by re-selecting an already-open chat — did not raise the keyboard. A plain requestFocus() isn't enough on Android: during startup the engine restarts its input connection and silently drops the TextInput.show request.

This adds a composer-owned helper, ensureComposerKeyboard, that focuses the message field and retries TextInput.show until the keyboard is actually up. It's invoked from the composer's initState, the app-resume path (StartupTasks), and IntentsService when re-opening an already-open chat.

Retry window: cold vs warm

• Warm opens use a short (~1s) window. In split-screen / multi-window (common on foldables) the IME doesn't resize the window, so neither viewInsets nor KeyboardVisibilityController ever report the keyboard visible; a long loop there would keep firing TextInput.show and re-raise the keyboard on every Back, making dismissal look broken.
• Cold (just-launched) opens use a longer (~5s) window, because a shortcut opening straight into a chat outlasts the engine's input-connection churn. A cold open is fullscreen and reports visibility, so the loop still exits the instant the keyboard is up and doesn't fight a dismiss.

Don't re-raise after dismiss

ConversationViewController releases composer focus on a genuine open→closed keyboard transition (scoped to the foreground chat), so the engine doesn't re-raise the keyboard for the still-focused field (flutter/flutter#52599). Android's IME swallows the dismiss Back before any PopScope handler runs, so the keyboard-visibility transition is the only place to catch it.

Stale overlay/sub-route guard

The retry loop bails while an overlay or sub-route is showing. Those flags live on the reused controller and are toggled by pickers / the details route / the share sheet; a skipped cleanup left one stuck true and blocked the keyboard on every later open ("works a few times then stops"). They're now cleared at the single entry point for every explicit keyboard-raise.

Controller lifecycle / render-crash fixes

Rapid navigation surfaced "FocusNode used after disposed" / "deactivated widget" render crashes, rooted in leaked ConversationViewControllers:

• FocusNodes and text controllers are now owned and disposed by the controller (onClose), not by the composer widget — so a reused controller never hands a freshly-mounted composer a disposed FocusNode.
• Controllers are disposed when their view is permanently gone (previously close() ran only on an explicit Back), and cvc() never returns a controller whose onClose() already ran.

Files

• conversation_text_field.dart — ensureComposerKeyboard / bounded, cold-aware retry loop; stale-flag reset; listeners added/removed (not disposing controller-owned nodes).
• conversation_view_controller.dart — exposes the hook; unfocus-on-dismiss; owns FocusNode/controller disposal; disposed guard; cancels the keyboard-visibility subscription.
• conversation_view.dart — dispose the controller when its view is gone (mobile).
• startup_tasks.dart — drive the keyboard through the composer helper on resume.
• intents_service.dart — raise the keyboard when re-opening an already-open chat.

Testing

Verified on a Samsung Fold (One UI), in split-screen and fullscreen, on a release/profile build: shortcut launches raise the keyboard reliably, Back dismisses without it popping back, and rapid back-and-forth no longer throws render errors.

Supersedes #3201.