fix: six defects a Rails application finds and a test suite cannot

[Halvanhelv]

Six defects the gem's own suite could not reach, found by installing it into
two real Rails applications and using it the way an application does — a
generator, a migration, controller actions, Puma with threads, replica
routing, PostgreSQL and MySQL — and fixed with each one reproduced in that
application first and again afterwards.

Nothing here is breaking for a PostgreSQL or SQLite user. A MySQL user with
the tables already created needs one ALTER TABLE, named in the CHANGELOG.

What was wrong

config.rate_limiter = :active_record crashed every translation unless
config.rate_limit was also set. build passed threshold: config.rate_limit
unconditionally, so an unset value overrode the very DEFAULT_THRESHOLD the
class defines for that case, and the caller got
ArgumentError: comparison of Integer with nil failed. Both limiters had it.

A translated sentence reached the error tracker. Rails'
DatabaseSelector sets prevent_writes on every GET, and the resulting
ActiveRecord::ReadOnlyError is not a StatementInvalid, so it escaped the
redaction — with the whole inlined INSERT, sentence included, in its
message. Observed through a real Rails.error subscriber. Every
ActiveRecordError on the write path is redacted now.

A failing cache write destroyed a translation already paid for. The
translator cached before it rebuilt, and nothing rescued, so a store failure
meant the provider had been billed and the caller got an exception instead of
the text. The cache is an optimisation: a failure is now rescued, logged,
reported as a new cache_error event carrying the provider and the error
class — never the text — and the translation is returned.

On MySQL one long sentence lost the whole batch. translation was
t.text, which MySQL caps at 65,535 bytes; a 75,000-byte run-on sentence
failed the upsert_all and cached none of the other fifty. The column now
carries limit: 16_777_215 — MEDIUMTEXT there, a no-op on PostgreSQL and
SQLite.

RateLimitExceeded said nothing. No threshold, no interval, no
namespace — an application catching it had nothing to log. It now names all
three, and none of them is content.

The rate limiter's own database failures surfaced raw. They are this
gem's TranslationDiff::Error now, redacted like the store's. It still
refuses rather than degrading, because it runs before the provider does and
nothing has been paid for yet.

What the verification pass then found

With the rescue in place, a genuinely broken cache — a role holding SELECT
but not INSERT — produced correct translations, zero cached rows, and an
empty log, because the gem logged only at debug while Rails runs at info
in production. An application would have paid the provider for every sentence
forever without a signal. That line is a warn now.

And docs/instrumentation.md promised cache_error's error field would
carry the adapter's class; for the SQL store it is always
TranslationDiff::Error, because the store redacts before the translator
sees it. Documented as it behaves, with the advice to alert on the event
rather than on a class name.

Verified, not assumed

Every fix was reproduced and re-checked in a real Rails 8.1 application:
replica routing with a live Rails.error subscriber, a SELECT-only Postgres
role, a DELETE-less role for the prune path, a 75,000-byte sentence against
real MySQL, and two rails runner processes for the cross-process cache hit
and the shared rate limiter. 40 threads against MySQL and 150 concurrent GETs
against PostgreSQL still produce exactly one row and lose no increments.

671 runs, rubocop clean. CI covers SQLite, PostgreSQL and MySQL.