fix(polls): stop scheduled polls shifting by the UTC offset

[ssavutu]

Reported on Discord: a poll scheduled for 9am saved as 5am.

Cause

The poll form's datetime-local inputs produce a zoneless "2026-08-07T09:00", and the page sent that string to the API verbatim. parsePollTime accepted zoneless layouts via time.Parse, which labels them UTC — so 9am Philadelphia was stored as 09:00Z and rendered back as 5am. The four hours is just the EDT offset; in winter it would have been five.

Fix

Frontend — localInputToISO runs the local wall-clock string through toISOString() before sending, on both create and edit. The browser is the only side that knows which zone the editor typed in. This is the same helper the article editor has had all along; polls never got one. Empty still maps to null, so "explicit null clears the date" on PATCH is unchanged.

Server — RFC3339 is now the only accepted form. The three old zoneless layouts are still recognised, but only so the error can name the problem:

timestamp "2026-08-07T09:00" has no UTC offset; send RFC3339 (e.g. 2006-01-02T15:04:05-05:00)

The four call sites were writing a bare "invalid starts_at"; they now wrap the parse error, and the polls page already renders body.error in its failure banner — so a stale browser tab hitting this gets a message that explains itself rather than a silent 400.

Notes for the reviewer

• Deploy ordering: the frontend fix must ship with or before the server, or the currently-deployed bundle's zoneless payloads start failing. Both halves are in this PR, so merging is enough — just don't cherry-pick the server change alone.
• Existing rows are still shifted. Rocco's poll is sitting at 05:00 and will fire then. Re-saving each affected poll through the fixed form corrects it (it loads showing 5am; retype 9am). Not done here.

Testing

TestParsePollTime covers absent / clear / offset-preserved / zoneless-rejected / nonsense. go build, go vet ./..., the handler suite, and frontend tsc --noEmit all pass.

🤖 Generated with Claude Code