fix(security): harden the replication surface (#103 + #104 + #105, rebased)

[kwhorne]

Supersedes #103, #104 and #105 — same commits, same authorship (@HelgeSverre),
sequenced and with their mutual conflicts resolved. Opening it here rather than on
the fork because Actions never started a single check-suite for any of the
three (total_count: 0, nothing awaiting approval), and a security fix should
not land on local verification alone.

Why this is urgent

The first one is exploitable in 1.9.8, released today. I reproduced it before
touching anything:

serve --listen 127.0.0.1:3460 --replication-listen 127.0.0.1:3461 \
      --auth root:adminpw:admin

→ connect to 3461, send zero bytes, receive 560 bytes containing the canary row

No handshake. The MySQL listener demands a password; the replication port
demanded nothing. The old guard only covered non-loopback binds, so
--replication-listen 127.0.0.1:… without a cluster secret let any local process
— or an SSRF payload that can open a TCP connection — read the entire database.

The other two are as real: a replica never verified its primary's identity, so
anything answering on the primary's address could inject fabricated rows even
with ELYRASQL_CLUSTER_SECRET set (auth ran one direction only); and
elyrasql replica had no auth flags at all, so its MySQL listener always ran open
— any username logged in as Admin over replicated production data. I confirmed
the last one in the CLI definition: Replica took only primary, data,
listen.

What I changed while sequencing them

The three were written independently against the same base and conflict with
each other, so they could not simply be merged in order:

• repl.rs: both fix(security): require authentication on the replication endpoint for every bind #103 and fix(security): mutual replication auth + replica refuses unauthenticated primaries #104 append a #[cfg(test)] mod tests with the
  same ENV_LOCK/set_env helpers. Production code merged clean; I rebuilt the
  test module to keep both suites (7 tests) over one copy of the helpers.
• docs/limitations.md, docs/security.md: fix(security): mutual replication auth + replica refuses unauthenticated primaries #104's text is a superset of
  fix(security): require authentication on the replication endpoint for every bind #103's — took fix(security): mutual replication auth + replica refuses unauthenticated primaries #104's.
• docs/replication.md: the two paragraphs are complementary (replication
  transport vs. the replica's MySQL listener) — kept both.
• CHANGELOG.md: mechanical. All three were written before 1.9.8 moved the
  decimal entries out of [Unreleased].

One real interaction, in its own commit: replica_auth.rs spawns
elyrasql replica, which after #104 refuses to start without a cluster secret.
Both its tests now set one. This only fails with all three applied — each PR
passes the suite alone, which is exactly the class of problem sequencing them
surfaces.

Testing

• cargo fmt --all --check
• cargo clippy --workspace --all-targets --all-features --locked -- -D warnings
• cargo nextest run --workspace --locked — 448/448
• Verified against a MySQL client

Each PR also verified individually merged onto main first: 443/443, 443/443,
441/441.

The exploit is closed, checked both ways:

• no cluster secret → the endpoint refuses to start, logs the reason, and the
  port is not listening (ConnectionRefusedError)
• secret set → an unauthenticated peer receives 16 bytes (the challenge) and no
  data; the canary does not leak

One design question for you

Without a secret, serve_replication returns Err and the caller logs
ERROR replication endpoint stopped — but the process keeps running and
serves normally, just without replication. That is fail-closed on the endpoint,
which is right, but an operator who passed --replication-listen and does not
read logs now has a silently non-replicating primary. Worth deciding whether that
should be fatal at startup instead. Not changed here.

Checklist

• Docs updated under docs/
• No internal engine/dependency names leak into SQL, errors, CLI, or the wire handshake
• Limitations documented honestly
• Scoped to a single logical change (one surface: replication auth)