fix: stop double-escaping what a provider sends back

[Halvanhelv]

Found by translating a real HTML article through the live Google and DeepL
APIs — not by a test, and not by three rounds of review before it.

What was broken

Every translation into English through Google or DeepL came back corrupted
wherever it contained an apostrophe, a quote or an ampersand:

in : <p>Он не увёл лодку.</p>
out: <p>He didn&amp;#39;t take the boat away.</p>

which renders on the page as didn't. English is full of apostrophes,
so in practice every Google or DeepL translation into English was damaged
somewhere.

Both vendors return entity-escaped HTML — confirmed against the raw APIs,
not inferred. The pipeline decoded entities on the way in, so a provider is
sent characters rather than entities, and re-encoded & and < at render
— but never decoded what the provider sent back. The vendor's & was
treated as a literal ampersand and escaped a second time.

The fix decodes a provider's returned text with the same decoder the input
path uses, in Translation::Response.build — the one place every provider's
output passes through, including the two that override translate entirely,
and including a provider somebody writes themselves.

The hole that opened, and closed

Decoding the vendor's < produced a bare <, and a bare < in front of
a letter is a tag. A provider returning <b attack put a real <b into
the rendered document:

<p>Value <b attack here.</p>      # tags found: ["<p>", "<b attack here.</p>"]

The second commit closes it: a translated < that is not shaped like a tag
is escaped on render, so a provider's markup survives and a provider's text
cannot become markup. The test that would have caught it is now there — the
tag count and tag sequence of a real HTML article must be identical before
and after a round trip through a vendor that escapes.

What changes for a user

A literal < in the source now comes back as < rather than bare.
if a < b then stop. becomes if a < b then stop., which is the correct
HTML encoding of that character and renders identically. Byte-for-byte
comparison against a previous version will show it. > is left alone; it is
unambiguous.

Warm caches keep the old text. A cache key is derived from the source
sentence, not from the stored value, so entries written before this fix keep
being served until they expire. Bump cache_namespace, or let cache_ttl
lapse.

Verified live

Both vendors, ru→en, through the gem's public API:

<p>He didn't take the boat.</p>
<p>5 &amp; 7 — these are important.</p>
<p>Compare: 5 &lt; 7 &amp;&amp; 7 > 5.</p>

A 68-tag article — lists, a table, a blockquote, a figure, an HTML comment,
an attribute carrying &, a notranslate span — round-trips with the
tag sequence identical, the span untouched, the link's attributes intact and
its text translated.

Also documented, because the same article exposed it: nothing tells the gem
that <pre> and <code> are code, so their contents are translated like
prose. class="notranslate" is the remedy.

684 runs, rubocop clean.