Design discussion: native popup UX for Option B (autocorrect-free text input)

## Description

Follow-up to the technical research done in #1612 for disabling native autocorrect on Android/iOS text inputs. The team decided to move forward with **Option B** — a native popup/dialog for typing (autocorrect off) instead of an engine-level fork change.

This issue tracks the design discussion needed before implementation starts.

## Context

Option B's main tradeoff is that typing happens in a native OS popup rather than directly in the field, which by default breaks live-filtering UX (e.g. Discover search results updating as you type). During the thread discussion, Mateo suggested we can pipe the live input from the native popup back into the UI so results still update as the user types — this needs to be designed/validated before implementation.

Other open questions for design:
- How the native popup should look/feel across the different input contexts (Discover search, profile name, nicknames, links, etc.) so it doesn't feel too far off from our UI.
- Whether a desktop fallback is needed, and what it should look like.
- Whether SDK scene inputs are in scope, or handled separately/later.

## Related Issues

- #1612 — Technical Research: Add configurable autocorrect option for native keyboard on Android and iOS (closed, resolved by choosing Option B)

Requested by Mateo via Slack