fix: quit promptly by sweeping engines once per shutdown - #137

The ten worker joins were ten separate `defer sup.Stop()` statements, and Go
runs deferrals one at a time, so teardown cost the sum of the per-worker exits
rather than the slowest one. The proxy and node-info both drain HTTP servers
on their way out, so on a loaded tree the sum is the difference between one
drain and several.

Fanning out is safe because no ordering between workers is left by then:
shutdownInferenceStack has already closed ingress at the proxy and waited out
the engine sweep, which are teardown's only two dependencies.

Joining concurrently also lets graceFor drop its engine-manager reservation.
That existed because engine-manager was joined late in the sequence and the
workers ahead of it decided how long it got; now they all read the same
remaining budget at once, and the reservation had become a penalty that cut
healthy workers to the floor.

Adds a warn-level per-worker breakdown when teardown is slow. The desktop runs
the broker at --log-level warn, so the existing diagnostics were absent from
exactly the logs collected when a user reports a slow quit: they only fire for
a worker that misses its grace, and a teardown that is merely the sum of prompt
exits trips none of them.

Signed-off-by: Terve <[email protected]>

The comment claimed startup was bound on "broker + proxy readiness", but
initializeConnector awaits only waitUntilReady, and readiness is
`isReady && brokerReady` where isReady just means the subprocesses were
spawned. Proxy readiness never held the Overview window closed, which matters
when reading startup latency: time-to-proxy-ready is not time-to-usable.

Signed-off-by: Terve <[email protected]>

system-architecture.mdc said the connector stays `connecting` until broker
app:ready "and the required Ollama proxy readiness" arrive. Only app:ready
gates it; proxy readiness is an asynchronous capability signal reported
afterwards, as tests/modular/modular-supervisor-readiness.test.ts asserts and
desktop/docs/services-backend.md already describes correctly.

Signed-off-by: Terve <[email protected]>

The unit guard in nvpair-engine-manager proves StopAll runs once, but nothing
covered the property that actually matters to a user: that the desktop's real
quit sequence, through the real broker and a real engine-manager, produces one
engine sweep rather than three.

This drives that sequence against an adopted engine -- a listener whose
readiness probe succeeds and which engine-manager never launched, so its stop
can only be declined and it stays marked running. That is the shape whose
repeat sweeps cost real seconds.

It counts sweeps rather than milliseconds so it cannot flake on a loaded
machine, and fails loudly if the engine was not adopted rather than passing
while covering nothing. Against the unguarded sweep it reports three sweeps and
a 2s longer teardown.

Signed-off-by: Terve <[email protected]>

TestStopAllWaitsForTheSweepInFlight checked the first caller's completion
with a non-blocking select. Both callers return when the sweep ends, but the
first goroutine's deferred close can land a moment after the second caller
returns, so a correct join could fail. It now waits briefly, still far less
than the probe an early return would skip.

TestQuitSweepsEnginesOnce's fixtures now use http.StatusOK and io.Closer
rather than a bare 200 and an anonymous interface, and its setup failures
say which step failed.

Signed-off-by: Terve <[email protected]>

Both documents said the broker waits for each worker without force-killing
it. The joins are concurrent within one teardown budget and escalate a worker
that misses its grace, except engine-manager on Windows, and engine-manager
now sweeps its engines once however many callers ask.

Signed-off-by: Terve <[email protected]>

The stopWorkers comment described what the previous defer order used to
allow, and the reportWorkerJoins comment recounted how a slow teardown was
first noticed. Neither says anything about the code as it stands; the
warn-level rationale is kept in present tense.

Signed-off-by: Terve <[email protected]>

With one sweep per process, a stop that failed in it was never attempted
again. A failed lms server stop leaves the command-mode engine marked
running, and the broker's own engine:prepare-shutdown and the stdin-EOF
path used to re-run doStop for it, so LM Studio could now outlive a quit.

Later StopAll callers still wait for the sweep and still skip adopted
engines whose stop is declined, which keeps quitting prompt. They now retry
the engines whose stop failed through a process handle or a stop command,
one caller at a time.

Signed-off-by: Terve <[email protected]>

The quit test counted every declined stop, so a real Ollama on the host
was adopted and declined in the same sweep and the test reported two
sweeps where one ran. It now matches the foreign engine by name.

It also checks the engine:get-installed reply for an error and, like the
desktop, closes stdin only once the engine:prepare-shutdown reply arrives,
draining both broker streams meanwhile.

Signed-off-by: Terve <[email protected]>

…eardown

stopWorkers now stops the proxy before fanning out the joins. On the
ordinary path shutdownInferenceStack has already stopped it and the second
stop returns at once; on an early Serve return, such as a failed app:ready,
it is what keeps inference from arriving while engine-manager stops its
engines.

The slow-teardown report timed only the concurrent worker joins, which
already have their own per-worker warning at the same threshold, and missed
the proxy join and the engine-manager sweep ahead of them. It now measures
from the start of teardown and names those phases alongside each join.

The README's shutdown paragraph now says which waits draw on the budget and
that escalation can add up to 4s past it.

Signed-off-by: Terve <[email protected]>

TestStopAllWaitsForTheSweepInFlight slept 100ms and assumed the goroutine
had taken the sweep by then. If it was scheduled late, the main call owned
the sweep and an implementation that returns early still passed. The
second call now waits until the first caller has set shuttingDown, which
only the sweep does.

TestStopAllSweepsOnce's doc now states the constraint without the old
timings.

Signed-off-by: Terve <[email protected]>

…rrent

The spec said engine:prepare-shutdown returns once every running engine
has been stopped. It returns once the sweep and any retry of a failed stop
have finished; a stop that still fails is logged, not returned.

frontend-api.md still said the connection waits for Ollama proxy
readiness. Only broker app:ready gates it, as main.ts and the other docs
already say.

The teardown test docs state what each test checks rather than how
teardown used to behave.

Signed-off-by: Terve <[email protected]>