Fix EQNotify tag matching: match at word start, not raw substring

[ebm5025]

Problem

A user received an EQNotify Telegram alert that felt unrelated to anything they'd signed up for. Root cause: tag matching used raw substring containment (content.includes(tag)), and several default tags are short — notably ct and kt. ct matches inside ordinary words like "contact", "protect", "select", so a batphone with any such word would trip the ct default and fire an alert.

(The empty-tags path was never the cause — matchesTags([]) correctly returns false. New subscribers simply carry the 9 default tags.)

Fix

Tags now match only when a word in the batphone starts with the tag (left word-boundary), instead of matching anywhere as a substring.

• ✅ Kills the mid-word false positives: ct matches "CT POP" but not "contact" / "protect".
• ✅ Preserves the intentional abbreviation/prefix triggers the defaults rely on: doze → "Dozekar", cazic → "Cazic-Thule", dain → "Dain Frostreaver". (Whole-word-only matching would have regressed these.)
• ⚠️ Tradeoff: a tag no longer matches mid-word, so quake no longer hits "earthquake". Add the fuller keyword if that's wanted.

Implemented with a left word-boundary regex over the lowercased content, with the tag escaped for regex safety (tags may contain punctuation like vulak`aerr).

Changes

• matcher.ts: matchesTags now uses a (?<[a-z0-9])<tag> word-start match; added escapeRegExp + a documented tagMatchesContent helper.
• Tests: added a word-start (prefix) boundaries block, including the reported ct-in-contact regression and the doze→Dozekar abbreviation case (17 tests total, all passing).
• Docs: /eqnotify add-tag description and README explain the word-start rule and the default tag set.

Testing

• yarn tsc — clean.
• yarn test:ci (eqnotify matcher suite) — 17 tests pass.

🤖 Generated with Claude Code

---

Generated by Claude Code