Fix/ses 5265 disappearing call messages

[ThomasSession]

SES-5265 - Reworking call control messages to respect the caller's expiry mode

[SessionHero01]

Context for this ticket:
Alice and Bob are contacts, fresh accounts

Alice sets disappearing messages, Bob doesn’t follow settings

Alice calls Bob

    Since Bob doesn’t have Calls permissions on yet, they see the Missed Call control message

    (Same behavior applies to the ‘Alice called you’ message) once Bob sets Calls perms  

Expected: On iOS, the call control messages have Alice’s disappearing message timer attached to them and the messages eventually disappear. From QA’s POV this makes sense since the call was coming from Alice

Observed: On Android the call control messages never disappear on Bob’s device.

[Copilot]

Pull request overview

This PR reworks how WebRTC call control/call-log messages determine disappearing-message expiry, aiming to use the caller’s expiry mode so call messages don’t unexpectedly disappear.

Changes:

• Thread ExpiryMode through call message persistence (StorageProtocol.insertCallMessage / Storage.insertCallMessage).
• Track inbound call context (callId + remote expiry) in CallManager and use it when inserting missed/incoming call log entries.
• Update call processing/bridging to pass the appropriate expiry mode when inserting call log messages and when dropping calls due to disabled call notifications.

Reviewed changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
app/src/main/java/org/thoughtcrime/securesms/webrtc/WebRtcCallBridge.kt	Passes expiry mode into call-log insertion (missed/outgoing) instead of the previous boolean flag.
app/src/main/java/org/thoughtcrime/securesms/webrtc/WebRtcCallActivity.kt	Removes trailing whitespace (no functional change).
app/src/main/java/org/thoughtcrime/securesms/webrtc/CallMessageProcessor.kt	Sets inbound call context on CallManager and persists missed-call records with the incoming message’s expiry mode.
app/src/main/java/org/thoughtcrime/securesms/webrtc/CallManager.kt	Adds inbound call context + updates call-log insertion API to require an ExpiryMode.
app/src/main/java/org/thoughtcrime/securesms/database/Storage.kt	Updates call-log persistence to accept an explicit ExpiryMode instead of deriving it from recipient settings.
app/src/main/java/org/session/libsession/database/StorageProtocol.kt	Updates storage interface to accept an explicit ExpiryMode for call-log insertion.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

insertCallMessage() computes expireStartedAt as currentTimeMillis() for any non-NONE expiry mode. This differs from the rest of Storage where expiry starts at sentTimestamp only for ExpiryMode.AfterSend and stays 0 for AfterRead. As written, AfterRead call messages will start expiring immediately, and AfterSend will use an inconsistent start time. Align expireStartedAt with the existing pattern (AfterSend -> sentTimestamp, AfterRead/NONE -> 0).

Suggested change

	val expireStartedAt = if (expiryMode != ExpiryMode.NONE) clock.currentTimeMillis() else 0
	val expireStartedAt = when (expiryMode) {
	is ExpiryMode.AfterSend -> sentTimestamp
	else -> 0
	}

[Copilot]

For outgoing calls, the call log entry is inserted with recipientRepository.getRecipientSync(recipient).expiryMode directly. Outgoing call control messages use applyExpiryMode(recipient), which applies coerceSendToRead(...) for CallMessage (since it sets coerceDisappearAfterSendToRead = true). To keep the stored call message’s expiry consistent with the actual call control messages (and with the previous Storage-side coercion), pass the coerced expiry mode here.

Suggested change

	recipientRepository.getRecipientSync(recipient).expiryMode
	applyExpiryMode(recipient)