Use the text already in the composer as the attachment caption

[hayaksi1]

Content

Typing a message and then picking an image opened the attachment preview with an empty caption editor, so the text had to be retyped, and the original was still sitting in the composer after the image was sent.

The composer's text now travels forwards to the preview as the initial caption, carried on the existing parcelable navigation target. A single room-scoped bit travels back to say that a handed-over caption was actually sent, keyed by Timeline.Mode, and the composer clears itself and deletes its saved draft on its next composition.

Clearing on send rather than on hand-over is deliberate. Cancelling the preview reports nothing, so the typed text is still there, restored by the composer's own saveable state and by the draft that Appyx's pause of the off-screen composer persists. If the back-channel bit is ever lost, for example to process death while the preview is open, the user keeps a duplicate copy of their text, which is a better failure than losing it.

Two cases are deliberately left alone. A pending edit hands over nothing and is not cleared, so the text being edited still edits the original on the next send. And MessageComposerEvent.SendUri, the share-into-app and keyboard-image path, bypasses the preview entirely and is unchanged.

Keying the hand-over on the timeline mode is what keeps a live composer and a thread composer from clearing each other; they share one room-scoped composer context, so a plain flag would not have been safe.

Motivation and context

Part of #5224.

Tests

features/messages/impl/.../attachments/AttachmentsPreviewPresenterTest.kt: a handed-over caption pre-fills the caption editor and no caption leaves it empty; sending reports the caption as sent, sending without one reports nothing, and cancelling reports nothing; sending in a thread reports the caption for that thread only.

features/messages/impl/.../messagecomposer/MessageComposerPresenterTest.kt: picking an image hands the composer text over, hands over nothing when the composer is empty, and hands over nothing while editing; the composer is cleared and its draft deleted once a handed-over caption has been sent; a caption sent in a thread does not clear the live composer.

Run with ./gradlew :features:messages:impl:testDebugUnitTest.

Rich-text formatting is flattened to markdown by the hand-over, which is what a caption can carry today; converting a caption to HTML is separate scope.

Tested devices

• Physical
• Emulator
• OS version(s):

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.

[codecov]

Codecov Report

❌ Patch coverage is 83.33333% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.64%. Comparing base (1279140) to head (5a51a87).
⚠️ Report is 5 commits behind head on develop.

Files with missing lines	Patch %	Lines
...s/impl/messagecomposer/MessageComposerPresenter.kt	75.00%	4 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #7465      +/-   ##
===========================================
- Coverage    80.66%   80.64%   -0.02%     
===========================================
  Files         2772     2773       +1     
  Lines        80812    80832      +20     
  Branches     11055    11058       +3     
===========================================
+ Hits         65183    65189       +6     
- Misses       11362    11381      +19     
+ Partials      4267     4262       -5     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.