fix: bound a COM call, and survive one that panics

[zcsizmadia]

Partially addresses #437 — deliberately not all of it, see below.

comSession.do inherited whatever context its caller handed down, and the supervisor hands down its process-lifetime context, which never fires. A wslservice that stopped answering parked the health tick forever — and tick holds the reconciler's mutex, so that is not one stalled call:

• every Demand() blocks, so every docker command hangs rather than failing
• the stats file freezes, so the tray cannot even show that the supervisor is stuck
• the poke loop never runs again

The COM rewrite (#380) made this worse, not better. Callers used to be separate processes shelling out to wsl.exe and could not affect one another; now List, Terminate and doctor all queue behind one unbuffered channel and one OS thread.

The bound

do() derives a bounded context. 20 s is far above any healthy call — the measurement that motivated this whole path was ~65 ms — so it fires only on a service that has stopped answering, never on a slow one.

Deriving (rather than replacing) keeps the caller's own cancellation winning when it is sooner, which matters because Fast.List tells the two apart: our deadline demotes the fast path and falls back to wsl.exe; the caller's own cancellation passes through without demoting.

The panic

Three separate things needed handling, and getting any one wrong is its own bug:

• without a recover, a panic on the apartment goroutine unwinds past the loop and kills the whole supervisor, bridge included
• a recover that reported success would be worse than the panic: list would return an empty slice and a nil error, so a machine with distros reports having none
• the recover is per call, not at the loop level, so the loop survives and later calls still work

Real trigger: unsafe.Slice(arr, count) panics if the service returns count > 0 with a nil array, and hr == 0 is the only guard.

What is NOT fixed, and why

tick still holds s.mu across the probe. Two reasons that is not in this change:

1. A tick-level deadline would be actively dangerous. Engine.Running returns a bool, so a timeout reads as "the engine is down" and tick would try to start an engine that is probably already running. That needs an "unknown" third answer first.
2. Moving the probe out of the mutex changes the reconciler's invariants — Demand could run between the probe and the decision, so tick would act on a stale reading. That deserves its own change with its own reasoning, not a rider on this one.

The COM bound is the part that is safe in isolation, because a failed list degrades to the wsl.exe path rather than to a wrong answer.

Verification

Both fixes have a negative control, run both ways:

control	result
bound removed	test times out after 45 s
panic reported as success	a panicking call reported success

Tests drive do() against a fake apartment loop of the same shape as the real one, so they run on any Windows machine rather than only one with a live wslservice. The timeout is a field with zero-means-default rather than a mutable package global, so shortening it in one test cannot leak into another in the same binary.