Closes #1148.

The MDX safety check in tools/check-docs-mdx only scoped docs/user/
and docs/integrator/. Since PR #1143 added docs/contributor/ to the
Fern sidebar, contributor docs are now MDX-rendered but were not
covered by the safety check. docs/contributor/validator.md slipped
through with an autolink (`<https://...>`) that breaks the MDX
parser on the `://` sequence.

Changes:

- Expand `SEARCH_DIRS` in `tools/check-docs-mdx` to include
  `docs/contributor/`.
- Add a fourth check: autolinks (`<https://...>` / `<http://...>`)
  outside fenced and inline code. MDX tries to parse them as JSX
  tags and chokes on the `://`. The fix is markdown link syntax
  `[text](url)`.
- Replace the offending autolink in
  `docs/contributor/validator.md:461` with a `[Chainsaw assert
  reference](url)` markdown link.

The 13 other `<word>` patterns the issue lists in validator.md
(e.g., `<phase>`, `<name>`) are inside inline code spans, which MDX
treats as literal `<code>` content — they are not parser-breakers
and intentionally remain (the placeholder convention is shared
across docs, including ones already in the user/integrator scope).
The new autolink check skips inline-code spans for the same reason.

Verified:
- `bash tools/check-docs-mdx` — green
- `make lint` — green
- Synthetic `<https://...>` test file flagged correctly

Both fixes were pre-existing bugs that the refactor preserved; the
review caught them as part of the new check pass:

- HTML comment rule was matching `$0` instead of the stripped `line`,
  which would false-positive on inline-code like `` `<!-- note -->` ``.
  Now matches `line ~ /<!--/` consistently with the bare-{ and
  autolink rules.
- Bare `{` regex `[^\\]{` required a preceding character, so `{foo}`
  in column 1 slipped through. Changed to `(^|[^\\])\{` so the
  start-of-line case is caught.

Verified with a synthetic test file under `docs/contributor/`:
- bare HTML comment outside backticks → flagged
- inline-code HTML comment → not flagged
- bare `{` at column 1 → flagged
- inline-code `{foo}` → not flagged

`make lint` green.