fix(webhook): say when a smart filter suppresses a delivery

A filter condition names a field, and `resolve` returns undefined when the
event's payload has no such field — so the condition fails and the delivery is
dropped. `message.ack` and `message.failed` carry `{ id, messageId, status, ack }`
and `message.reaction` carries `{ messageId, chatId, reaction, senderId }`; none
has a sender or a body. A `sender` filter therefore suppresses all three.

That is the filter behaving as specified. What was missing was any way to learn
it had happened: `dispatch()` awaits an empty array and returns, no metric is
emitted, and the delivery-failure table records only deliveries that were
ATTEMPTED. An operator whose webhook stopped firing had nothing to read.

Suppression is now logged at debug, with the count and the payload's own field
names — that list is usually the answer, because the cause is a condition on a
field the event does not have. Debug rather than warn: suppression is the normal
outcome of a filter doing its job, and a warn would be noise for correct usage.

Also corrects two payload descriptions. `session.qr` was documented as the raw
QR string; both adapters render it with `qrcode.toDataURL` before invoking the
callback, so the event carries a PNG data URL — the same value the REST QR route
returns. And the filter field list now states that its fields exist on only some
message events, with the recommendation to scope by `events[]` rather than to
rely on a filter being inert.

No matching semantics change. A filter that fired before still fires, and one
that suppressed still suppresses.