fix(channels): return channel messages instead of an always-empty list (#625)

[rmyndharis]

Summary

Fixes #625. On the whatsapp-web.js engine, GET /api/sessions/:sessionId/channels/:channelId/messages always returned an empty array (200, content-length: 2) even for channels with messages.

Root cause

The adapter resolved the channel with client.getChannelById(channelId), but whatsapp-web.js 1.34.x has no getChannelById method on its Client. A hand-written BusinessClient type falsely declared it, so the compiler was satisfied while the runtime call threw TypeError: ...getChannelById is not a function. A try/catch then swallowed that into []. GET /channels (list) was unaffected because it uses the real getChannels().

The same phantom call sat in getChannelById (the GET /channels/:channelId detail endpoint), which therefore always resolved to null.

Changes

• getChannelMessages now resolves the channel from getChannels() — whose items are real Channel instances that carry fetchMessages() — and reads its messages. The error is no longer swallowed.
• An unknown/unsubscribed channel now returns 404 via a new ChannelNotFoundError (a NotFoundException subclass, mirroring the existing MessageNotFoundError) instead of a silent empty 200. This maps to 404 through NestJS's built-in handler with the message intact and is consistent with GET /channels/:channelId, which already returns 404 for the same condition.
• getChannelById (detail endpoint) now resolves from the subscribed-channel list, so it returns the channel (or null → 404 at the service) instead of always null.
• Removed the phantom getChannelById from the BusinessClient type.

Notes

whatsapp-web.js reads channel messages from the session's local message store (Channel.fetchMessages walks the in-memory store + loadEarlierMsgs). This change makes the endpoint actually return whatever the engine has synced; for a freshly-subscribed channel whose history has not yet hydrated locally, the store can still be sparse. That is a separate engine-level limitation, independent of the always-empty bug fixed here.

The Baileys engine is unaffected: its channel methods intentionally reject with EngineNotSupportedError (channels are a whatsapp-web.js-only feature), so they fail explicitly rather than returning a misleading empty list.

Verification

• New adapter specs cover: fetch via getChannels() (not the phantom method), 404 on unknown channel, empty channel → [], and getChannelById → null for an unknown id.
• Full backend suite green (1932 tests), lint and build clean.