Ping every member

What it does

An admin types /everyone (or @everyone) and the bot pings every member it has ever seen in that group: one or more @mention messages in the chat — split into multiple messages if the list is too long for one — followed by a private message to each member with a link back to the call. The first message starts with a count of how many known members are being pinged.

Behaviour that must not change

Two triggers work and always must: /everyone and bare @everyone, exactly as v1 shipped them. The group ping text is byte-identical to v1's, including the always-English "Number of known users:" header on the first message only, and the same 4096-character chunking boundary. Only a group admin can run it — an anonymous "group" sender (posting as the channel) counts as an admin, same as everywhere else in the bot.

Two things are deliberately not the same as v1, and both are recorded in the contract: if the bot cannot confirm who the group's admins are, v1 let anyone ping everyone — v2 refuses instead. And v1 quietly forwarded the triggering message to the bot's owner every tenth private message it sent; v2 does not do this at all, to anyone, under any circumstance.

QA's spec spells the trigger /ping everyone, a phrase v1 never shipped. It is not an alias of /everyone — it is a different two-word command QA invented — so it is recorded as a trigger mismatch rather than wired up as one (docs/site/content/docs/feature-map.mdx).

The private messages themselves are sent by cb-worker, not by the reply that answers the group — a big group can have hundreds of members, and nothing that slow belongs on the path that has to answer Telegram fast.

How to verify it

qa/features/util_everyone.feature — three scenarios, run with python scripts/cb.py test. By hand in the sandbox: have a couple of accounts talk in the group first (that registers them, same as /shipp), then run /everyone as an admin and watch both the group message and the follow-up DMs arrive.