Extracted field values can contain double-encoded UTF-8 (mojibake)

Problem/Motivation

Field values extracted by a crawl can contain double-encoded UTF-8. A
correctly-encoded multi-byte character (e.g. an en dash, non-breaking
hyphen, or curly quote) gets re-encoded a second time somewhere in the
fetch/parse pipeline, producing a visibly wrong character (e.g. â
in place of a dash) plus invalid raw control bytes embedded alongside it in
the stored string.

This happens during extraction itself. It's visible directly in a crawl
target's field mapping Preview output, before any node is
created or updated. It isn't a display-only glitch: the corrupted text
contains actual invalid control characters, which can cause external
services that consume the content afterward to reject it outright. We saw
an AI embeddings API return a hard error on any text containing this
corruption.

On one real-world crawl target, roughly 43% of resulting articles (139 of
326) had at least one instance of this in their body content.

Steps to reproduce

1. Configure a crawl target against a page containing an em dash, en dash,
   non-breaking hyphen, or curly quotes in its body content.
2. On the target's field mapping page, use Preview against
   that page's URL.
3. Expected: the extracted value renders the punctuation
   correctly.
4. Actual: the extracted value shows a corrupted character
   (visually â) in place of the punctuation, and the underlying
   string contains invalid control bytes alongside it.

Proposed resolution

Two parts:

1. Add an automatic normalization step in the extraction pipeline that
   detects and reverses double-encoded UTF-8 in every extracted field value,
   for every crawl target, before it's written to a node. This should detect
   the double-encoding pattern itself, not match a fixed list of known-bad
   characters, so it also covers punctuation not yet seen in testing.
2. Identify why the fetch/parse step produces bytes that end up
   double-encoded in the first place, and fix that at the source so the
   corruption stops being generated at all. This may involve how fetched page
   content's charset is detected/handled during parsing.

Remaining tasks

• Confirm the exact point in the fetch/parse pipeline where the
  double-encoding is introduced.
• Add a regression test with a fixture page containing known problem
  characters (em dash, en dash, non-breaking hyphen, curly quotes) asserting
  correct extraction.
• Implement the fix per "Proposed resolution" above.
• Document the fix in the changelog.