fix(group-translate): make the group introduction opt-in and off by default

[rmyndharis]

Problem

Enabling this plugin made it post a 👋 Translation bot… introduction into a group the first time it saw any message there. The check sat at the very top of the message path, ahead of every other condition:

if (!state.announced) {
  await this.gateway.sendText(sessionId, msg.chatId, buildHelpText(this.opts.prefix));
  state.announced = true;
}

State is per chat, so this fired once per group — a single enable announced the bot into every group the WhatsApp account belonged to, as each of those groups saw its next message. The account running a plugin is normally a real person's WhatsApp rather than a dedicated bot number, which makes the blast radius somebody's entire group list.

Change

The introduction now sits behind a new announceInGroups setting, default false — in the manifest and, independently, in the code that reads it. An install upgrading from an earlier version has no stored value for the key, so it stays silent without operator action.

Defaulting it off costs nothing:

• the same text is still available to anyone on demand via /tr help
• translation already required an admin to run /tr on in that specific group
• denial replies were already off by default

This was the only place the plugin spoke without being addressed; every other send is a reply to a /tr command or a translation in a group where an admin turned it on.

Tests

The regression test asserts the default configuration — the value that shipped the harm — and checks both that nothing is sent and that an ordinary group message is not claimed. Removing the guard fails it on the send it must not make. Two more cases cover the opt-in path announcing once per group, and /tr help still answering regardless of the setting.

The pre-existing concurrency test used the announcement as its observable for the per-chat lock; it now opts in explicitly, so what it proves is unchanged.

Full suite 529/529, typecheck and catalog check clean.