Fix schemas for non-string widget options

[Sanjays2402]

Fixes #62.

AppTest preserves the current value's type for non-string options but stringifies the option list. Include the observed typed value alongside the accepted string forms so selectbox, radio, select-slider, and multiselect values satisfy their advertised enum.

Added a regression covering all affected widget kinds; it fails without the source change and passes with it.

[dkedar7]

Thanks for this @Sanjays2402 — the core insight is right and it's the one I'd have reached for: the widget protobuf carries options already stringified (options: "2023"), so the current value's type really is the only evidence of the true option type available at runtime. I confirmed that directly against AppTest before touching anything.

I've pushed two commits on top (maintainer edits were enabled — shout if you'd rather I hadn't) to close two gaps:

1. The enum only expressed the selected option in its typed form. On selectbox('Pick', [1,2,3]) sitting on 1, the branch advertised {"enum": [1, "1", "2", "3"]}. The reported value is a member of its own enum — the invariant #62 names — but an agent that wants to select 2 is told only "2" is valid, while set_widget(id, 2) is in fact accepted (#51). Since the point of the schema is to let an agent construct any valid set, the typed form is now recovered for every option: {"enum": [1, 2, 3, "1", "2", "3"]}, which is also what the issue's suggested fix asked for.

That recovery is guarded by a str(recovered) == option round-trip check, so a typed member always denotes the option it came from. It matters for two cases the direct approach would get wrong: mixed lists ([1, 'two', 3.0] → 'two' and '3.0' stay string-only rather than being dropped or mis-parsed), and bools — bool('False') is True, which would have advertised a member the widget rejects.

2. The default=[2] added to TYPED_OPTIONS_APP. That edit made the multiselect assertion pass, but it also removed the only no-selection case in the fixture — and no-selection is exactly where this approach has nothing to key off. I've restored the original st.multiselect('Nums', [1,2,3]), added a separate picked widget with a default, and asserted the empty case explicitly: its enum stays the string form, which is still correct and settable (verified set_widget('nums', ['2']) → [2]), just less informative. Documented as a deliberate limitation rather than left as a silent hole.

I also resolved the merge against #61, which landed a few minutes ago — the selectbox/radio null special-case this branch was written against is gone, replaced by a value-keyed _make_nullable, so a placeholder with typed options still round-trips null through the shared path.

Verified on the CLI and over the real MCP stdio transport (this project's bar for a dogfood fix), plus 6 regression tests — 3 of which fail against the unfixed schema path.

Merging this as yours. Genuinely useful contribution — thanks for digging into a subtle one.