fix(lifecycle): re-read container state after start instead of assuming "running"

[AbstractNucleus]

What: After docker_client.start() returns, lifecycle.py writes "running" to the DB. But Docker start returns once the container process is launched, not when the JVM is up.

Why: Operators see a green "running" pill instantly even though the server can't accept connections for many seconds. Confusing during start-stop cycles.

Approach: After start(), re-read the container's actual Docker state (and ideally probe RCON or the listener port) before writing to the DB. The lifecycle poller would correct it within a tick anyway, but the user-facing transition should be honest.

[AbstractNucleus]

This was generated by AI during triage.

Routed to ready-for-human — choosing the readiness probe is a design call:

• Re-read Docker state only (cheap, still gives a false "running" while JVM warms up).
• Probe the listener port (closer to truth, but needs a timeout policy).
• Probe RCON (closest to truth, but requires the password to already be loaded).

The honest behaviour depends on which signal we trust. Worth a human picking before an agent commits to one.

[AbstractNucleus]

Triage note: the issue body picks the right shape but the open design call is which signal to trust for the post-start re-read. Three options, each with a different trade-off:

1. Docker container state (cheap, already what the lifecycle poller reads). Tells us the container process is up; says nothing about whether the JVM has bound to the listener port. So we'd still write running while the server is in fact unreachable — only marginally better than what we have today.
2. TCP probe to the listener port (one socket connect, ~ms). Tells us something in the container is listening, which is closer to operator intent. False positives are basically nil because the port wouldn't be bound until the JVM opens it.
3. RCON handshake (heaviest — requires a working RCON password and the RCON port to be open). Tells us the Minecraft server is actually accepting commands — the strongest signal — but introduces a dependency on RCON being correctly configured. If RCON is mis-set, every start will look stuck even when the server is fine.

Recommendation hierarchy is (2) > (3) > (1) on cost/benefit, but (3) is the only one that catches "JVM crashed during world load after binding the port."

Which signal should the post-start re-read trust? Happy to implement once that's pinned.

[AbstractNucleus]

Stopping before implementation — hitting the stop condition on the state-model gap. Posting the analysis so a human can pin direction.

Setup

• docker_client.start() already wraps c.start() in a 30s timeout (PR fix(lifecycle): add timeouts to docker start/stop/restart calls #142). Adding a post-start TCP probe to 127.0.0.1:<server["variables"]["port"]> is straightforward — the synchronous socket.create_connection(..., timeout=0.5) pattern is already proven in server_variables_form.check_port_bound (PR fix(new-server): surface rollback errors + reject already-bound host ports #151), and asyncio.to_thread would keep the route async-clean.
• Success path is unambiguous: probe binds within budget → write "running". That part fits naturally.

Gap: no "container up but not yet listening" state

The enum of state values that the panel writes is fixed by lifecycle_state.py:

• _RUNNING_LIKE = {"running", "paused"}
• _STOPPED_LIKE = {"created", "exited", "dead"}
• _TRANSIENT = {"restarting", "removing", "scaffolding"}
• plus "unknown" from discovery when Docker is unreachable

None cleanly carries "Docker says container is up, JVM hasn't bound the port yet":

• restarting is Docker's own restart-loop state; reusing it would conflate two genuinely different conditions and break any future discovery sync that trusts Docker's own state strings.
• scaffolding and removing are mcontrol-owned but mean specific other things.
• unknown means "Docker daemon unreachable", not "container starting up".
• Leaving the row untouched on probe-timeout falls back to the pre-start state ("exited" etc.), which would re-enable the Start button while the JVM is mid-warmup — worse UX than today.

The implementation note suggested "starting", but no such value exists in the model.

Second gap: no periodic poller to converge

The handoff plan assumes "the regular lifecycle poller takes over." There isn't one — discovery.run_discovery only runs at app startup (decision 021 / 033 are explicit: "the state pill is also not polled — it updates only on operator action"). So whichever state we write on probe-timeout will stick in the DB until the operator restarts the panel or hits the Rescan button.

What I'd want pinned before continuing

One of:

1. Add a new state literal (e.g. "starting") to _TRANSIENT in lifecycle_state.py, plus a state-pill style for it. Probe-timeout writes this, and discovery's next read (rescan or app restart) corrects to "running". Lowest-surface change, but introduces a state that doesn't map to any Docker state — discovery would need a deliberate mapping (probably leave "starting" rows alone if Docker still reports the container as "running", to avoid the pill snapping back the moment discovery runs).
2. Skip the timeout branch entirely — block the route up to N seconds, return "running" if the probe wins, return a flash error and leave state untouched if it loses. Reuses the existing _lifecycle_flash.html plumbing from PR fix(lifecycle): add timeouts to docker start/stop/restart calls #142. No new state value. Trade-off: operators wait up to 10s on the lifecycle-button click.
3. Make discovery periodic so probe-timeout can write some honest intermediate value and let convergence handle the rest. Multi-file refactor — out of scope for this issue.

Option 2 stays inside the existing model and matches PR #142's surface area. Option 1 is the cleanest model-wise but requires a new state literal — explicitly out of scope per the issue's stop conditions.

Standing down until direction is pinned.