feat(rcon): allow administrator-defined endpoints

docs/architecture.md

@@ -10,7 +10,7 @@ User authentication begins with an opaque, short-lived, single-use token created
 
 ### RCON administration
 
-The administrator console stores one or more internal Minecraft RCON endpoints with write-only AES-GCM-encrypted passwords. Browser requests invoke authenticated server actions; only the Next.js runtime opens RCON TCP connections. Exact deployment-managed endpoint allowlisting prevents the connection registry from becoming an arbitrary internal network proxy. Commands and responses are bounded and ephemeral, while credential-safe audit events retain the operator, server, command verb, keyed digest, outcome, and duration. RCON is exposed only through internal cluster services and never through public ingress.
+The administrator console stores one or more RCON endpoints with write-only AES-GCM-encrypted passwords. Browser requests invoke authenticated server actions; only the Next.js runtime opens RCON TCP connections. Administrators may configure any syntactically valid DNS hostname and port without deployment-managed endpoint configuration; IP literals remain rejected. Commands and responses are bounded and ephemeral, while credential-safe audit events retain the operator, server, command verb, keyed digest, outcome, and duration. Production Minecraft RCON is exposed only through internal cluster services and never through public ingress.
 
 ### Discord bot
 
@@ -30,7 +30,7 @@ The admission decision is fail closed. Unknown players, disabled effective group
 - Velocity requests use hashed per-server bearer credentials, timestamps, and database-unique request IDs for authentication and replay prevention.
 - Session and one-time-code values are random and stored only as hashes.
 - Exact IP addresses are sensitive data and require an explicit retention policy before production deployment.
-- RCON hostnames and ports must match the deployment allowlist on save and use; passwords never cross the browser trust boundary.
+- RCON endpoints require syntactically valid DNS hostnames and ports; passwords never cross the browser trust boundary. Cluster egress policy and administrator authorization constrain the resulting outbound-connectivity trust boundary.
 - RCON commands and responses are untrusted, bounded, rendered only as text, and excluded from persistent history and logs.
 
 ## Database invariants

docs/rcon.md

@@ -4,13 +4,9 @@ The administrator RCON console proxies commands through the Next.js server runti
 
 ## Application configuration
 
-Set `RCON_ALLOWED_ENDPOINTS` to a comma-separated allowlist of exact internal `host:port` pairs:
+Administrators may configure any syntactically valid DNS hostname and TCP port without deployment-managed endpoint configuration. IP literals, trailing-dot hostnames, and malformed DNS names are rejected whenever a connection is saved, tested, or used.
 
-```text
-RCON_ALLOWED_ENDPOINTS=season4.somc.svc.cluster.local:25575
-```
-
-IP literals, trailing-dot hostnames, malformed DNS names, and endpoints absent from the allowlist are rejected whenever a connection is saved, tested, or used.
+This flexibility means an authorized or compromised administrator can make RCON connection attempts to any DNS hostname and port reachable from the web runtime. Use cluster egress policy and administrator access controls to constrain that trust boundary where required.
 
 Saved passwords are encrypted with AES-256-GCM and connection-bound authenticated data. By default, domain-separated credential and audit keys are derived from `AUTH_SECRET`. Deployments may instead provide independent 32-byte base64 values through `RCON_CREDENTIAL_KEY` and `RCON_AUDIT_KEY`. Rotating the credential key requires replacing saved RCON passwords.