Stop a finished colony taking answers it can never deliver

[ParallelEntrepreneur]

An answer could still be submitted after a colony had ended, and the card then sat there saying it was sending — for an agent that is gone.

Three defects, each enough on its own

1. The card is a form. The submit button was disabled, but Enter in any field submits a form and a disabled button does not stop that. submit() now refuses unless answering is possible, which is where the guard belonged.

2. The inputs stayed live, so the card invited an answer it could not send. The fieldset is disabled with the rest now.

3. It said the wrong thing. !canAnswer always rendered "Reconnecting to the colony…" — including when the colony had finished and there was nothing to reconnect to. It now distinguishes disconnected from ended.

And why it looked like it was working

client_command dropped the command silently when the colony was not live (sessions.rs). The browser had already marked the question as sending — that is the spinner — and nothing ever came back to clear it.

It now answers with the session instead, so a client whose view is stale corrects itself and stops offering to answer. The predicate has a name and a test:

fn accepts_commands(status: SessionStatus) -> bool { status.is_live() }

Publishing is included in the refusal: by then the microVM is already gone.

Verified in the browser

Against the mock, stopping a colony with its question card open:

Footer	"This colony has finished, so the agent cannot be answered."
Submit button	disabled
Controls	8 of 8 effectively disabled (:disabled via the fieldset)
Clicking a radio	no change
Submitting the form the way Enter does	nothing sent, no spinner

Before the fix the footer read "Reconnecting to the colony…" and that last row sent an answer into nothing.

cargo test -p colonizer-harness    147 passed, 0 failed   (1 new)
cargo check                        0 warnings
npx tsc --noEmit                   clean

One note on the check I ran first: input.disabled reads false for controls inside a disabled <fieldset>, because the property reflects the element's own attribute rather than inherited state. matches(':disabled') is the honest check, and by it all eight are disabled.