Keep typing in the composer instead of the keyboard's fullscreen editor

[hayaksi1]

Content

When the window is short — landscape, or a large display size — the keyboard replaces the whole
screen with its extract editor. That editor belongs to the IME, not to us: it is a plain text field
with none of the composer's mention pills, none of the message being replied to, and none of the
room behind it. It is also what the report describes as the composer swallowing input.

Setting IME_FLAG_NO_EXTRACT_UI on the plain-text composer turns it off, so what the user types goes
to the composer itself whatever the screen height.

The rich text composer is EditorEditText, owned by matrix-rich-text-editor, so it needs the same
flag set there; this only covers the plain-text one.

Motivation and context

Part of #2153. Honest limitation: the report is from 0.4.0, against the composer as it was before the
rewrite, and I could not reproduce the swallowed input on a current build — the "Direct Messages" in
its title looks like a red herring, since nothing in the composer branches on whether the room is a
DM. So treat this as removing the fullscreen editor because it is wrong for this composer, which also
removes the most likely cause of what was reported, rather than as a confirmed fix.

Tests

• MarkdownTextInputTest — asserts the flag is set on the editor the composer creates. An IME flag
  has no behaviour a unit test can drive, so this guards the setting rather than the outcome.
• Negative control: removing the line fails that test.
• ./gradlew :libraries:textcomposer:impl:testDebugUnitTest :libraries:textcomposer:impl:ktlintCheck :libraries:textcomposer:impl:detekt — green.

Tested devices

• Physical
• Emulator
• OS version(s): unit tests only; the fullscreen editor itself needs a short window to appear

Checklist

• I am aware of the etiquette.
• This PR was made with the help of AI:
  • Yes. In this case, please request a review by Copilot.
  • No.
• Changes have been tested on an Android device or Android emulator with API 24
• UI change has been tested on both light and dark themes
• Accessibility has been taken into account. See https://github.com/element-hq/element-x-android/blob/develop/CONTRIBUTING.md#accessibility
• Pull request is based on the develop branch
• Pull request title will be used in the release note, it clearly defines what will change for the user
• Pull request includes screenshots or videos if containing UI changes
• You've made a self review of your PR

[github-actions]

Thank you for your contribution! Here are a few things to check in the PR to ensure it's reviewed as quickly as possible:

• If your pull request adds a feature or modifies the UI, this should have an equivalent pull request in the Element X iOS repo unless it only affects an Android-only behaviour or is behind a disabled feature flag, since we need parity in both clients to consider a feature done. It will also need to be approved by our product and design teams before being merged, so it's usually a good idea to discuss the changes in a Github issue first and then start working on them once the approach has been validated.
• Your branch should be based on origin/develop, at least when it was created.
• The title of the PR will be used for release notes, so it needs to describe the change visible to the user.
• The test pass locally running ./gradlew test.
• The code quality check suite pass locally running ./gradlew runQualityChecks.
• If you modified anything related to the UI, including previews, you'll have to run the Record screenshots GH action in your forked repo: that will generate compatible new screenshots. However, given Github Actions limitations, it will prevent the CI from running temporarily, until you upload a new commit after that one. To do so, just pull the latest changes and push an empty commit.