fix(security): mutual replication auth + replica refuses unauthenticated primaries

[HelgeSverre]

Summary

A replica applies everything its primary streams to it, but it never verified the primary's identity: auth_connect only proves the replica to the primary. Any host accepting TCP connections on the primary's address could impersonate it (the transport is plaintext unless cluster TLS is configured) and feed the replica arbitrary snapshot/write frames — fabricated tables, tampered rows, corrupted catalog state — which the replica then served to clients.

Demonstrated end-to-end against main (dd0ed82) with a ~60-line Python fake primary:

1. Real primary seeded with repl_t(id, secret) = (1, 'REPLICATION_CANARY_SECRET'); snapshot captured from its replication port.
2. Fake primary replays the captured snapshot with one value tampered in place.
3. Stock replica bootstraps from it and serves the tampered row to clients:

== replica serves table repl_t with rows: ((1, 'XXXXXXXXXXXXXXXXXXXXXXXXX'),)
== ==> ARBITRARY DATA INJECTION INTO REPLICA CONFIRMED

Note this works even when ELYRASQL_CLUSTER_SECRET is set on the primary: the fake primary reads the replica's proof, ignores it, and streams data anyway — nothing ever checks the other direction.

Fix

• New handshake steps auth_verify_peer (replica challenges, verifies constant-time) and auth_respond_to_peer (primary answers). Order: auth_connect → auth_verify_peer → Hello → data. Bounded by a 5 s timeout so a stalling peer cannot hang the reconnect loop.
• run_replica fails closed when no cluster secret is configured unless ELYRASQL_ALLOW_OPEN_AUTH=1.
• Tests: duplex-pair handshake unit tests (shared secret OK / wrong secret rejected), startup refusal test, and an end-to-end primary→replica snapshot test over real TCP.

Breaking change

Primary and replica must be upgraded together (the handshake changed). Mixed versions fail closed at connect rather than silently degrading. Replicas now require ELYRASQL_CLUSTER_SECRET.

Verification

Re-ran the fake-primary attack against this branch:

=== A) replica WITHOUT secret: must refuse to start ===
   exit=75  refused-with-clear-error=True
=== B) replica WITH secret vs fake primary: must not apply data ===
   injected table visible via SQL: False
   injected bytes present in data file: False
=== RESULT: EXPLOIT BLOCKED ===

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

Depends conceptually on #103 (same guard philosophy); conflicts are trivial if ordering matters.

[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.