v0.5.2

Ask the host what it supports instead of assuming

Forms landed in PyHiroba on 2026-08-09, and Talk.form() kept warning that
they do not work there. The gate was in_browser(), which only reports
whether js.pyhirobaAsk exists — that answers "can this host run a model",
never "can this host return a form value". Those were the same question
right up until they weren't, and the warning then sat on top of a form
that worked, telling teachers the opposite of the truth. It was enough to
hold the vendored copy back at 0.4.0.

The host now publishes what it implements as pyhirobaFeatures, and the
gate reads that. Matching is whole-token against the comma list rather
than substring, so ai-probe alone cannot pass for ai.

A host that publishes nothing is treated as old-but-unknown, not as
feature-less: ai.stream() still probes ai-ask-start and falls back if it
is refused, exactly as before. Only a host that does name its features is
taken at its word, which spares it a round trip that is certain to fail.
That distinction is what keeps a host which implemented streaming before
the feature string existed from being demoted.

Docs said forms do not work in PyHiroba in four places, which is now
false everywhere it appeared. FORMS.md and the request letter are marked
resolved and kept as the record — including which of the four open
decisions went which way.

Streaming stays unimplemented on the host side and needs nothing from us;
it degrades to whole-answer replies as designed. Adding ai-stream to the
feature string is all that will be required to switch it on.