fix(security): require authentication on the replication endpoint for every bind

[HelgeSverre]

Summary

The replication endpoint hands a full copy of the database to every connecting peer. It previously refused only non-loopback binds without ELYRASQL_CLUSTER_SECRET — so a listener on 127.0.0.1 without a secret let any local process (or an SSRF payload able to open a TCP connection) exfiltrate the entire data set.

Demonstrated live against main (dd0ed82) on macOS/Linux-equivalent loopback:

$ elyrasql serve --data ... --listen 127.0.0.1:13309 \
    --replication-listen 127.0.0.1:13310 --auth root:adminpw:admin
$ printf '' | nc 127.0.0.1 13310 | strings | grep CANARY
REPLICATION_CANARY_SECRET        # <- entire keyspace dumped, zero bytes sent

No handshake is required: on EOF-without-Hello the server treats the peer as a fresh replica and streams the whole snapshot.

Fix

• Require ELYRASQL_CLUSTER_SECRET on every bind address, loopback included.
• Keep ELYRASQL_ALLOW_OPEN_AUTH=1 as the explicit opt-out (consistent with the existing guards).
• Add unit tests pinning all three guard outcomes (refused / secret OK / explicit opt-in OK).
• Update docs/security.md, docs/limitations.md, docs/configuration.md, CHANGELOG.

Breaking change

Deployments that relied on an unauthenticated loopback replication endpoint must now set ELYRASQL_CLUSTER_SECRET (recommended) or opt out explicitly. Primary and replicas should be upgraded together; mixed versions fail closed at the handshake rather than silently degrading.

Verification

• cargo test -p elyra-server — 221 passed (3 new)
• cargo clippy -p elyra-server --all-targets -- -D warnings clean
• cargo fmt --all -- --check clean

[kwhorne]

Merged as part of #107 (185cd7d) — your commit, your authorship, plus a Co-authored-by trailer on the squash.

Consolidated rather than merged one by one for two reasons.

Actions never ran on any of the three. total_count: 0 check-suites on each head commit, and nothing sitting in the approval queue — so there was no CI signal at all on a security change. Reopening them from a branch in this repo was the only way to get one. #107 is green on all 8 checks.

They conflicted with each other, not just with main. #103 and #104 both append a #[cfg(test)] mod tests to repl.rs with the same ENV_LOCK/set_env helpers; the production code merged clean, and the resolution keeps both suites over one copy of the helpers. docs/limitations.md and docs/security.md took #104's wording (a superset of #103's); docs/replication.md kept both paragraphs, since they cover different surfaces.

One genuine interaction needed a commit of its own: replica_auth.rs spawns elyrasql replica, which after #104 refuses to start without ELYRASQL_CLUSTER_SECRET. Both its tests now set one. That only fails with all three applied — each of your branches passes the suite alone (443, 443, 441).

I reproduced the #103 finding against 1.9.8 before touching anything: zero bytes sent to the replication port, 560 bytes back with the canary row in them. Verified closed both ways afterwards — without a secret the endpoint refuses to start and the port does not listen; with one, an unauthenticated peer gets the 16-byte challenge and nothing else.

Thanks — this was a real hole in a shipped release.