Keep reply reference when restoring a message draft

[jancborchardt]

When drafting a reply to a message via the reply function, then switching to a different conversation or app and then back to Talk, the reply reference is lost.

It is especially strange since the reply reference (the original message) is shown above the saved draft. But on sending, it seems to get lost as it is not shown on the sent message.

🏁 Checklist

• ⛑️ Tests (unit and/or integration) are included or not needed
• 🔖 Capability is checked or not needed
• 🔙 Backport requests are created or not needed: /backport to stable-xx.x
• 📅 Milestone is set
• 🌸 PR title is meaningful (if it should be in the changelog: is it meaningful to users?)

🤖 AI (if applicable)

• The content of this PR was partly or fully generated using AI

[github-actions]

APK file: https://github.com/nextcloud/talk-android/actions/runs/30374841322/artifacts/8695317018
To test this change/fix you can simply download above APK file and install and test it in parallel to your existing Nextcloud app.
(please click on link to get QR code displayed)

[mahibi]

I will merge as it fixes the bug.
However the fix unveils that a single source of truth is missing here.

I did not dive into, for now just a snippet from a chat with claude:

Q: having both                                                                                                                                                                                        
messageInputViewModel.getReplyChatMessage.value?.jsonMessageId,                                                                                                                        
and
chatViewModel.messageDraft.quotedJsonId,                                                                                                                                            
sounds complicated?                                                                                                                                                                                

A:                                                                                                                                                                                  
● Yes, and the complication isn't really in resolveReplyToMessageId() itself — it's that the PR is patching over an existing split in how "the message being replied to" is represented:             
                                                                                                                                                                                                     
  - messageInputViewModel.getReplyChatMessage — a live ChatMessage object, held only in memory, used for the "just tapped reply" UI/session state.                                                   
  - chatViewModel.messageDraft.quotedJsonId (+ quotedMessageText/quotedDisplayName/quotedImageUrl) — a flattened, persisted subset of the same info, kept in sync by hand in                         
  MessageInputFragment.initObservers() (line 220-224) every time the first one changes.                                                                                                              
                                                                                                                                                                                                     
  So there are two stores for one concept, manually kept in sync in one direction (live → draft), but never synced back (draft → live) after the live one is wiped by activity recreation. That's the
  actual complexity — this function is just the symptom showing up at the one call site (getReplyToMessageId()) that needs the ID at send time.                                                      
                                                                                                                                                                                                     
  A cleaner fix would restore a single source of truth: when restoreState() detects isInReplyState() (draft.quotedJsonId != null), also repopulate messageInputViewModel's reply state from the      
  draft, so every consumer (not just getReplyToMessageId()) sees one consistent value and this fallback function wouldn't be needed at all. That's larger in scope though — it touches restore-flow  
  code and would need a ChatMessage-shaped object rebuilt from the draft's flattened fields (or a type change), versus this PR's one small pure function plus tests.                                 
                                                                                                                                                                                                     
  So: not wrong, but it is a local patch over a pre-existing dual-state design rather than a fix of the root duplication. Worth a comment on the PR if you want to flag it as a possible follow-up,  
  but not a blocker for merging this fix.  

I guess the code regarding replies should be simplified in general..