V17.4.16

Close the three remaining queue-wedge sites in out-node.js surfaced by a systematic audit of processMessage — issue #450 audit.

V17.4.14 and V17.4.15 each fixed one queue-wedge mechanism. A full audit of every code path in processMessage for the "we're done with this message but never called processNext" anti-pattern found three more sibling sites, all warn-but-don't-dispatch → processing[chatId] stays true forever → subsequent messages on that chat silently park.

Sites fixed

1. case 'mediaGroup' else branch when msg.payload.content is not an array — warns "msg.payload.content for mediaGroup is not an array of mediaItem".
2. default case when type isn't a method on the bot — warns "msg.payload.type is not supported".
3. else of if (msg.payload.type) — payload with no type field — warns "msg.payload.type is empty".

Fix: node.queueManager.processNext(chatId) after each warn so the queue head is released.

Also examined (not a wedge)

case 'mediaGroup''s inner validation loop breaks out of the for loop on a bad item but control falls THROUGH to the sendMediaGroup(...) dispatch (with invalid content). Bot returns error → processError → queue advances. Not a wedge, just a misleading warn since the bot is called regardless. Left as-is.

Tests

3 new mocha regression cases (one per fixed branch), same "two messages, first hits the no-dispatch path, second proves the queue advanced" pattern as the V17.4.14 / V17.4.15 tests. 245 passing.

Queue-wedge coverage now complete

All five no-dispatch paths in processMessage are closed across V17.4.14 / V17.4.15 / V17.4.16. The V18 beta line carries the same three fixes in d0d2875.