[WEBJS][PLUS] send/buttons/reply drops selectedButtonId under @lid addressing → button click never delivered

[frontalinilucas]

Environment

• WAHA: 2026.7.1 (PLUS), engine WEBJS, devlikeapro/waha-plus, native linux/amd64.

The bug

Since our account was migrated to @lid addressing, POST /api/send/buttons/reply no longer produces a valid button response. The outgoing message is stored as type: buttons_response but with the selectedButtonId field missing, and it is authored from our @lid identity.

The exact same button clicked manually from the native app works: that response is authored from our @c.us identity and keeps selectedButtonId.

So the click id — the only thing that identifies which button was pressed — is lost specifically on the @lid send path. This is engine/addressing-level; it is independent of the counterpart.

Minimal comparison (same account, same button)

WORKS  (manual click, native app):
  type: buttons_response
  selectedButtonId: <present>          <-- e.g. "si" or a JSON payload id
  from: <account>@c.us                 <-- PN addressing

BROKEN (POST /api/send/buttons/reply):
  type: buttons_response
  selectedButtonId: <absent / null>    <-- DROPPED
  from: <account>@lid                  <-- LID addressing

Both authored by the same account; only difference is the sender addressing and the presence of selectedButtonId. HTTP 201, ack: 2 in both cases — it's delivered, but without the id.

Reproduction

1. Account on @lid addressing (incoming chats show <id>@lid).
2. Receive an interactive buttons message (WEBJS incoming has _data.isDynamicReplyButtonsMsg = true + _data.dynamicReplyButtons, or a classic buttonsMessage).
3. POST /api/send/buttons/reply with the correct selectedButtonID + selectedDisplayText (tried chatId as both @c.us and @lid).
4. Inspect the stored outgoing message → selectedButtonId is gone, from is @lid.

Whether the counterpart reacts is just circumstance

The underlying defect is the same regardless of counterpart. Two observed behaviors, same root cause:

• A counterpart that routes on the quoted text still advances (so a sendText with reply_to quoting the buttons message is a partial workaround).
• A counterpart that routes strictly on selectedButtonId gets nothing usable → the flow stalls, and there is no workaround because no WAHA engine can currently emit the id under @lid.

Cross-engine

• WEBJS: drops selectedButtonId under @lid (this report).
• GOWS and NOWEB: POST /api/send/buttons/reply returns 501 Not Implemented.
  → There is currently no engine that can send a working interactive/button response for an @lid account.

Ask

1. WEBJS: include selectedButtonId when authoring a buttons_response / interactiveResponseMessage while the account is on @lid addressing.
2. And/or expose an interactive / nativeFlow response endpoint carrying the button id, implemented across engines (GOWS/NOWEB currently 501).

Full raw payloads (incoming buttons message + both outgoing buttons_response raws) and logs available on request.