fix(linkify): prevent .tld suffix from matching inside href URLs (#817)

[Mukller]

Problem

Fixes #817.

When a docstring contains a Markdown/reST hyperlink whose URL ends in a TLD that
matches a project identifier (e.g. https://example.com when com is a function
name), pdoc produces corrupted HTML like:

<a href="https://example<a href=" #com"="">.com</a>"&gt;something

Root Cause

The linkify regex in render_helpers.py includes a leading optional group:

(?<![/=?#&\.])   # lookbehind: not part of a URL
(?:
    \b(?!\d)\w+  # normal word start
    |
    \.*          # zero or more leading dots (relative references like .Foo)
)
(?:\.(?!\d)\w+)+ # one or more .word suffixes

When \.* matches zero characters, the lookbehind is evaluated at the position
immediately before the first . of the dotted suffix. In href="https://example.com",
that position is after the e in example. e is a word character — not in
[/=?#&.] — so the lookbehind passes, .com is matched as a relative reference,
and is replaced with <a href="#com">.com</a>, corrupting the surrounding href.

Fix

Add \w to the negative lookbehind:

- (?<![/=?#&\.])  # heuristic: not part of a URL
+ (?<![/=?#&\.\w])  # heuristic: not part of a URL or word

A . immediately preceded by a word character is always part of a larger token
(a URL segment, a dotted name already caught by the \b\w+ branch, etc.) and can
never be the first character of a standalone relative reference. Existing relative
references like .Foo appear after whitespace or punctuation, not after \w, so
they are unaffected.

Verification

# module: issue/__init__.py
def com():
    \"""
    [something](https://example.com)
    \"""

# Before fix: <a href="https://example<a href=" #com"="">.com</a>"&gt;something
# After fix:  <a href="https://example.com">something</a>

[Mukller]

Code Review

Correctness of the Fix

Root cause: linkify's regex contains \.* (zero or more dots) as one branch of
the first optional group. When this branch matches zero characters, the lookbehind
(?<![/=?#&\.]) is evaluated at the position just before the first . of the dotted
suffix. In example.com, that position is after e — a word character not in the
lookbehind set — so the check passes and .com is matched erroneously.

Fix: adding \w to the lookbehind prevents any .-led match when the immediately
preceding character is a word character. This is correct because:

scenario	char before .	lookbehind ([/=?#&.\w])	outcome
https://example.com	e (word)	blocked ✓	.com no longer matched
see .Foo	(space)	passes	.Foo still matched
(invoke .bar)	(	passes	.bar still matched
foo.bar.baz	o, r	blocked	already caught by \b\w+ branch

No Regressions

• Relative references (.Foo, ..Foo) in prose always follow whitespace or
  punctuation. Adding \w to the lookbehind does not affect them.
• Normal dotted identifiers (foo.bar) are matched by the \b\w+ branch, not
  \.*, so the lookbehind position differs and they are unaffected.
• Other URL heuristics ((?![/#]) lookahead) remain unchanged.

Change Size

One character added to a character class in one regex. Risk of unintended breakage
is minimal.