feat(rcon): diagnostic for stale RCON password after server.properties change

[AbstractNucleus]

What: When the operator changes rcon.password in server.properties but the running server still has the old password cached, RCON fails opaquely.

Why: Classic source of "why won't the console connect" pain. The diagnostic is straightforward but currently invisible.

Approach: When RCON auth fails, check if the on-disk server.properties password differs from the last-loaded value for the running container. If so, surface a banner — "RCON password changed on disk but server is still running with the old value — restart required."

[AbstractNucleus]

This was generated by AI during triage.

Routed to ready-for-human — diagnosing stale RCON auth requires deciding what state to track:

• Last-loaded password per running container? (where does that state live?)
• Re-read server.properties on every RCON connect attempt and compare?
• Hash-only comparison to avoid keeping the plaintext in app memory?

Each has security/complexity trade-offs. Worth a human deciding the state model before an agent implements.

[AbstractNucleus]

Triage note: this is doable as a standalone banner, but worth a scope check before starting.

Option A — ship now, standalone. Diff the current on-disk rcon.password against the last-loaded value for the running container, surface a banner on RCON auth failure. Small, self-contained, lands quickly.

Option B — fold into #123 loader work. If the loader-aware UI is going to touch the server-detail page anyway, the banner could ride along and avoid two passes over the same template region.

Recommendation: A, unless #123 is imminent. The diagnostic is independently valuable and doesn't actually depend on the loader column.

Which way?