v0.5.1

Run the form's work on its own loop, not Colab's

The diagnostic settled it. In Colab the click handler runs, and all three
ways of writing to an Output widget reach the screen — so neither the
callback nor the write was ever the problem. What never happened was the
work itself: a coroutine handed to ensure_future from that callback sits
in the queue and is never executed.

Colab does not pump the event loop between cell executions, and nothing
about the loop says so — asyncio.get_running_loop() returns it reporting
running=True, which is why this read as a display bug for so long. The
field cleared because that happens synchronously in the handler; the
answer never came because the coroutine producing it never started.

So the widgets path now runs its coroutine on a thread with a loop of its
own, which does not care whether the host is pumping anything. Writing
through `outputs` is what makes this safe from another thread: it is a
traitlet assignment over the comm, with none of display()'s dependence on
the executing cell. The other two paths keep their existing behaviour.

The test pins the property that actually matters: press submit, then give
the loop no further turns at all — the tests run the whole thing inside
asyncio.run and let it exit — and the answer still has to arrive.
Restoring ensure_future fails it.

threading joins the ui allowlist for this. It is imported inside the
function and only on the ipywidgets path, so PyHiroba, which has neither
IPython nor ipywidgets, never reaches it and never asks Pyodide for a
thread. Noted in the integration doc as that guard demands.