fix(security): require accounts on the replica MySQL listener

[HelgeSverre]

Summary

elyrasql replica had no auth flags at all and always started its MySQL listener with open authentication — any username/password logged in as Admin, with full read access to the replicated (often production) data set:

WARN elyra_server: authentication is OPEN (no credentials required, every client gets Admin)
...
$ mysql -h 127.0.0.1 -P 13312 -u attacker -panything -e "SELECT * FROM production_table"
...succeeds...

serve mode defaults to 127.0.0.1 with a safe-by-default refusal for remote binds, but replicas are typically part of real deployments and there was no way to configure accounts at all.

Fix

• Add --user/--password/--auth USER:PASS:ROLE to the replica subcommand, mirroring serve.
• Refuse to start a credential-less replica listener unless ELYRASQL_ALLOW_OPEN_AUTH=1 explicitly opts in.
• Make elyra_server::env_flag public so the CLI reuses the library's truthy-value parsing (1/true/yes/on).
• New CLI test file pinning both outcomes (refusal with explanatory error; authenticated startup reaches a listening MySQL port).
• Update docs/security.md, docs/replication.md, CHANGELOG.

Breaking change

Scripts starting replicas without accounts must add auth flags or set ELYRASQL_ALLOW_OPEN_AUTH=1. The refusal happens before any file I/O, so nothing is wiped or half-started.

Verification

• cargo test -p elyra-cli — 5 passed (2 new: replica_refuses_credential_less_listener, replica_starts_with_configured_accounts)
• cargo clippy --workspace --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.