feat(plugins): group auto-translation extension plugin

[dallascyclist]

Summary

Ports the WhatsApp group auto-translation feature (originally proposed as a core module in #278) to a first-party EXTENSION plugin, built on the Tier-2 capability layer from #294. The translation logic was already isolated behind ports, so the framework-agnostic core lifts in unchanged; the OpenWA wiring is now ctx.messages / ctx.engine / ctx.storage. Registered disabled by default — enable via POST /plugins/translation/enable.

Supersedes #278. Thanks for landing #294 so quickly — ctx.messages/ctx.engine are exactly what this needed.

How it maps to the Tier-2 layer

• ChatGateway → ctx.messages.sendText/reply (sends routed through MessageService, persistence preserved) + ctx.engine.getGroupInfo (admin resolution).
• ConfigStore → ctx.storage (one GroupState JSON per group).
• Config → ctx.config (manifest configSchema; defaults to http://localhost:7001).
• Hook → ctx.registerHook('message:received', …) in onEnable.
• The core (coordinator, command parser, reply formatter, ports) is reused unchanged.

What's included

• src/plugins/extensions/translation/ — the plugin: core/ (reused), libretranslate.client.ts (timeout + circuit breaker), plugin-chat.gateway.ts, plugin-config.store.ts, index.ts, manifest.json.
• Registered (disabled) in ExtensionsRegistrar, mirroring auto-reply.
• One small engine passthrough: mentionedIds on IncomingMessage (whatsapp-web.js already attaches it). It enables @mention command targeting — the reliable cross-user identity under LID, since mentions and message authors share the @lid namespace.

Behavior

Per-message source detection (LibreTranslate) with learn-by-observation of each participant's language; one combined quote-reply per message into the other participants' languages; never translates a message into its own language (resilient to detector misfires on colloquial text). In-group /tr commands (on/off, setlang, auto, ignore/unignore, grant/revoke, status, help) — every command replies. Permissions: group admins (LID-aware via the group owner) plus admin-delegated members. The bot's own sends are fromMe and route through message:sent, so there is no translation loop.

Configuration

libretranslateUrl (default http://localhost:7001), libretranslateApiKey?, timeoutMs, commandPrefix (/tr), minLength, maxLength, denyReply — see manifest.json configSchema; set per-instance via the plugins config API.

Testing

• 543 unit tests pass (the lifted core suite + the new ctx-backed gateway/store shims + the mentionedIds mapper cases); lint + format clean; build clean.
• The shared core was validated end-to-end against live WhatsApp + a self-hosted LibreTranslate in feat: WhatsApp group auto-translation (LibreTranslate) #278, which shook out four real bugs — all fixed and carried into this core.

Known limitations / follow-ups

• Cross-user targeting under LID works via @mention; non-owner admin auto-detection on a differing scheme could build on the new senderPhone / RESOLVE_LID_TO_PHONE ([Feature]: How we can get phone number from @lid #263) — a follow-up.
• onGroupJoin for announce-on-add (currently announces on first activity); per-plugin send throttle; media/caption translation; dashboard config UI — all follow-ups.
• LibreTranslate add the ability to use a remote LibreTranlate via configurable API key / URL