fix: bound the group-translate skip filter and scope the chatwoot reply mapping

[rmyndharis]

Two defects on the message path, both reachable from ordinary traffic and both reproduced before being fixed.

group-translate — a group message could stall the plugin worker

The filter that skips messages with nothing to translate was one regular expression:

/^(?:\s|\p{Emoji}|https?:\/\/\S+)+$/u

\p{Emoji} matches ASCII digits, # and * — they are keycap-sequence components — so the emoji branch also matched the \S+ inside the URL branch. Every additional link-shaped token multiplied the backtracking space:

tokens	length	test()
6	97	70 ms
7	113	174 ms
8	129	811 ms
9	145	5 526 ms

The identical payload written with letters instead of digits completes in 0.0 ms, which isolates the cause. maxLength defaults to 2000 characters, JavaScript regex execution cannot be interrupted, and any member of a group with translation on could send such a message — so the time is spent holding the worker's event loop outright.

The filter now splits on whitespace and checks each token, which is linear and needs no backtracking. Same input: 5 526 ms → 0.08 ms, and flat at 3200 characters.

Switching the emoji test to \p{Extended_Pictographic} — the property that actually means "picture character" — fixes a second consequence of the same overlap: a message of 1 or #5 was classed as emoji-only and silently left untranslated.

chatwoot-adapter — an agent reply could reach the wrong customer

Chatwoot conversation ids are per-account autoincrement, so two accounts relayed by one gateway share one routinely. Beside the tenant-scoped reverse mapping (wa:<session>:<id>), an unscoped one (wa:<id>) was rewritten on every link, so it held whichever session linked last. A delivery that arrived without a session scope resolved through it and was sent to that session's chat — one customer's agent reply delivered to another customer's number.

Unlinking by conversation id, which the 404 recovery path does, deleted that shared mapping as well — silently dropping the other tenant's replies until their next inbound message rebuilt it.

The unscoped mapping is now claimed only while it is unclaimed, and marked unusable once a second session claims the same id. Nothing in a scope-less delivery identifies its tenant, so there is no right answer to guess: it is dropped and logged instead. Unlink removes the mapping only when it belongs to the session being unlinked.

Compatibility. Mappings written before scoping keep resolving, and a single-tenant host is unaffected — the unscoped key is still claimed and still used. One echo-loop test relied on the old guess; it now supplies the session scope such a delivery carries in practice, which is what it meant to exercise, and a new test pins the drop.

Verification

• 577 tests pass, typecheck clean, catalog up to date, all 10 plugins build and load.
• Both fixes are test-first: the filter test failed at 2 983 ms before the change, and the mapping test resolved to the wrong tenant.