fix(wwjs): finish applying #762's honesty rule to status posts and acks

[rmyndharis]

The rule #762 set

Client.sendMessage() can resolve with undefined rather than throw. An absent message cannot distinguish "nothing was sent" from "sent, id unreadable", and claiming success for the first is unrecoverable — so it throws. A present Message proves dispatch, so an id it cannot read there carries the empty sentinel, and $1 is read before falling back to it (#747).

toStatusResult sits directly beneath toMessageResult and the doc-comment stating that rule. It followed none of it:

private toStatusResult(msg: Message | undefined): StatusResult {
  const ts = msg?.timestamp ? new Date(msg.timestamp * 1000) : new Date();
  return { statusId: msg?.id?._serialized ?? '', … };
}

Two defects

1. It fabricates a 201. Status posts reach the identical Client.js path, so undefined carries the identical ambiguity. Instead of failing, it returned 201 with an empty statusId and a new Date() invented on the spot — for a status that may never have been published. Exactly what the comment above it forbids.

2. It discards a readable id — and this is the more reachable half. It never tries $1, so on a renamed build a status that posted perfectly well returns statusId: "". deleteStatus takes that id as its revoke handle, so the status can never be taken down.

That half is not theoretical. Unlike an ordinary send, a status post still succeeds on an unpatched build: Injected/Utils.js returns the constructed msg on the status branch before ever reaching the Msg.get that fails elsewhere. So the one path that still works when others 500 is the one that loses its id.

The ack listener

Same missing fallback. #765 was right to drop an unreadable id rather than pass undefined into an UPDATE that TypeORM turns into waMessageId = NULL — that guard stays. But it dropped ids readable as $1, stranding the message at sent forever, including the ack < 0 that is the only signal a send failed outright.

Blast radius — traced, not assumed

• No new HTTP behavior class. A send whose toMessageResult throws already surfaces as a 500: failSend → toClientFacingError passes a plain Error through, and there is no global exception filter. A status post throws bare because it has nothing to persist (status echoes are deliberately not stored) and no hook to fire. Same outcome, same reason.
• No Swagger change. fix(wwjs): report sends honestly when the engine returns no usable message #762 did not document a 500 on the send routes; this stays consistent with that.
• No openapi.json delta — no controller or DTO touched.
• Baileys deliberately untouched. Its send path (:525, :1578) and status path (:1631) both use the empty sentinel, so it is self-consistent. Only whatsapp-web.js disagreed with itself, and changing Baileys would need its own analysis of what undefined means there.
• !msg is now impossible past the guard, so the msg.timestamp ? … : new Date() fallback now only covers a present message with no timestamp — where the post is proven and only the clock is unknown. Unchanged on purpose.

Tests

Six new cases; all six fail against the previous adapter (5 failed / 173 passed before the ack case was added). They cover: $1 recovered on a status post, unreadable id → sentinel, all three post methods rejecting on undefined, and $1 recovered on an ack. The existing status specs pinned only happy paths, which is why this shipped green.

Verification

• eslint 0 errors · prettier clean · npm test — 188 suites, 2444 passing (was 2438; +6)

Refs #747, #762, #765.