bug: resolveLeetSpeakTransformer breaks trailing word boundary when ! follows a word

[JayQuerido]

Expected behavior

When using a pattern with trailing word boundary like pattern|fuck|``, the text "fuck!" should match because ! is a non-word character in the original input, and a common ending to sentences.

Actual behavior

"fuck!" does not match. The leet speak transformer converts ! to i, resulting in "fucki", which causes the trailing \b to fail since there's no word boundary between k and i.

Minimal reproducible example

import { RegExpMatcher, pattern, englishRecommendedTransformers } from 'obscenity';

const matcher = new RegExpMatcher({
  blacklistedTerms: [{ id: 1, pattern: pattern`|fuck|` }],
  ...englishRecommendedTransformers,
});

console.log(matcher.hasMatch('fuck'));   // true
console.log(matcher.hasMatch('fuck!'));  // false (should be true)

Steps to reproduce

1. Create a matcher with a pattern that has word boundaries at both ends (|word|)
2. Use englishRecommendedTransformers (which includes resolveLeetSpeakTransformer)
3. Test with a word followed by !
4. Observe that the match fails

Additional context

This appears to be a regression (this didn't happen in 0.4.0). The leet speak dictionary now includes ! as a variant of i (useful for catching "pen!s"), but this breaks word boundary detection for common sentence-ending punctuation.
The issue is that word boundaries are evaluated on the transformed text rather than the original text positions.

Node.js version

v20.x (issue is not Node-version-specific)

Obscenity version

v0.4.5

Priority

• Low
• Medium
• High

Terms

• I agree to follow the project's Code of Conduct.
• I have searched existing issues for similar reports.

[JayQuerido]

I found the commit: fa673e6

It was released in 0.4.2

[jo3-l]

Thank you for the report and for the investigation. I am a bit hesitant to revert the offending commit because it seems valid by itself (it's just triggering a bug elsewhere) and the built-in pattern for fuck does still match on fuck!. To be clear, I absolutely plan to address this issue eventually by fixing the word boundary code.

That said, if this issue is causing problems for you directly in production, I am willing to consider temporarily reverting the commit you mention. (Note that you can also work around this problem directly without changes in the library code by passing a custom set of transformers when building the profanity matcher.) What do you think?