Outgoing messages not respecting chat's disappearing-messages timer → recipient sees "This message will not disappear" / older-version warning (v0.7.1)

[rapharibeir0-ai]

Summary

When a recipient's chat has disappearing messages enabled, messages sent through any /send/* endpoint arrive without the chat's ephemeral timer. The recipient's WhatsApp then shows an info ("i") badge on the message and the dialog:

"This message will not disappear."
"The person may be using an older version of WhatsApp."

The message is delivered and readable — this is cosmetic — but it makes API-sent messages look broken/untrustworthy to end users, and the "older version of WhatsApp" wording is misleading (the sender is the API).

Environment

• Evolution Go v0.7.1 (latest tag, self-hosted)
• whatsmeow-based stack
• Recipient: regular/consumer WhatsApp with disappearing messages turned on for that chat

Steps to reproduce

1. On a consumer WhatsApp, enable disappearing messages for a chat with the connected instance's number.
2. Send a plain message from the API:

   POST /send/text
   { "number": "<recipient>", "text": "hello" }
   

3. Server responds HTTP 200 with a real message ID ("message":"success", Type: ExtendedTextMessage).
4. On the recipient device, the message arrives with an info "i" badge; tapping it shows "This message will not disappear / the person may be using an older version of WhatsApp."

Expected behavior

Outgoing messages should inherit the chat's disappearing-messages timer, i.e. be sent with the proper ephemeralExpiration / ContextInfo.Expiration (and EphemeralSettingTimestamp) matching the chat's app-state setting — so no warning is shown.

This is the same class of bug documented in Baileys: WhiskeySockets/Baileys#1687 — "Send message is not respecting chat disappearing mode" → "The message should be sent with chat default disappearing mode if ephemeralExpiration option is not set."

Suggested fix / questions

• Does the instance sync chat app-state (disappearing timer) and apply it on send? It appears not to.
• Could /send/* either (a) auto-apply the chat's synced ephemeral timer, or (b) expose an optional expiration (seconds) field so callers can set it explicitly?

Notes

• Reproduced live; all /send/* calls return 200 success regardless, so the HTTP layer gives no signal that the ephemeral marker is missing.
• Low severity (cosmetic), but affects perceived reliability of API-sent messages to any contact using disappearing messages.