feat(parsers): format-specific right-boundary guards for IP/MAC/UUID/JWT/SSN

[Copilot]

dot() consumes any non-word char as a trailing delimiter, causing parsers to accept structurally invalid prefixes (e.g. 1:2:3:4:5:6:7:8:9 matches as the 8-group IPv6 prefix; 123-45-6789-00 matches as SSN).

New primitives (src/common.ts)

• boundary(p) — zero-width word boundary; succeeds if next char is \W or EOF, does not consume the delimiter
• strictBoundary(p, extraPattern) — same, but additionally rejects specific non-word structural chars

These sit alongside dot(), which is left unchanged to avoid breaking compound parsers (Range, Time.Relative) that rely on child parsers consuming trailing whitespace.

Per-parser migrations

Parser	Boundary	Structural char rejected
Language	boundary()	— (enables English+14155552671 → two entities)
UUID	strictBoundary	-
JWT	strictBoundary	.
SSN	strictBoundary	-
MACAddress	strictBoundary per format	: / - / . (own separator only)
IPv4	ipv4Boundary()	\w and . followed by digit (5th octet), but not sentence period
IPv6 full	strictBoundary	: (9th group)
IPv6 compressed	ipv6CompBoundary()	: and . followed by digit

IPv4-mapped IPv6 correctness fix

::ffff:192.0.2.128 previously failed because hexChain greedily consumed ffff:192 as two hex groups. Added a new hexGroupsPrefix regex (/(?:[0-9a-fA-F]{1,4}:)+/) that requires a trailing : per group, paired with a new IPv6v4Mapped parser tried before IPv6Compressed.

// Before
"::ffff:192.0.2.128" → no match (greedy hex chain consumed ffff:192)

// After
"::ffff:192.0.2.128" → { ip: "::ffff:192.0.2.128", version: 6 }
"::192.0.2.128"      → { ip: "::192.0.2.128", version: 6 }

Tests added

All prefix-rejection cases from the issue, IPv4-mapped IPv6 variants, English+14155552671 producing both a language and phone entity, and sync/async scanner parity for all affected formats.

• Fixes parsers: format-specific boundaries for IP/MAC/UUID/JWT/SSN #5