feat: Add option for creating polls - #6260

`scripts/Dockerfile` only ever built the Go backend and just COPYed the
repo's checked-in placeholder server/router/frontend/dist/index.html
("No embeddable frontend found.") into the go:embed path, relying on a
comment telling whoever builds the image to run `pnpm release` first and
have it land in the build context. The project's own CI does that (a
separate frontend job uploads/downloads the dist folder around the Docker
build), but a plain `docker build -f scripts/Dockerfile .` - what the
Dockerfile itself claims to support - skips that step entirely, so the
placeholder gets embedded and every page shows the literal error text.

Add a frontend build stage (node:24-alpine + pnpm, matching the lockfile
and patches under web/) that runs `pnpm release` and gets copied over the
placeholder before `go build` runs, so the image is self-contained. Frontend
source was previously excluded from the build context entirely
(.dockerignore had a blanket /web/ rule); replace that with narrower rules
for its generated/local-only output (node_modules, dist, coverage, etc.)
so the source is available to the new stage without bloating the context.

Verified by running the same `pnpm install --frozen-lockfile` / `pnpm
release` / `go build` steps the new stage runs and confirming the served
root page is the real app rather than the placeholder text (no Docker
daemon available in this sandbox to run `docker build` itself).

The poll vote endpoints built a voter's public resource name as
"users/{numeric id}" (e.g. "users/1"), but every other endpoint in this
codebase - and the User.name the frontend actually receives from
useCurrentUser() - uses "users/{username}" (see BuildUserName in
user_resource_name.go). PollBlock.tsx picks out the caller's own vote by
comparing vote.voter to currentUser.name, so that comparison silently
never matched: votes persisted and tallies updated correctly (the option's
progress bar filled in, which read as "highlighted"), but the selected
option's radio/checkbox circle never got its border or checkmark.

buildPollVotesResponse now batch-resolves each vote's voter ID to a
username via store.ListUsers and builds the name with BuildUserName,
matching the format the frontend already compares against.

Verified end to end: create user, sign in, cast a vote, and confirm the
response's voter/currentVoterName now agree (both "users/<username>"),
which is what PollBlock.tsx needs to render the checkmark. Full go test
./... still passes.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_016UZX8r5o3xdW8uKDTQv6Mb

Poll patch fix small issue

…schema

An earlier commit added a poll binding table and a memo_id column to
poll_vote by editing the already-shipped 0.32/00__poll_vote.sql migration
in place, rather than adding a new one. Schema version tracking is a
monotonic per-version marker (system_setting), not a hash of each file's
content, so a database that had already recorded schema version 0.32.1
from that file's original (poll_vote-only) content never re-ran it -
editing an applied migration file has no effect on anyone who already
applied it. Every such database was stuck at the old shape while the
application code (the memo-deletion cascade, EnsurePollBinding) assumed
the new one, so every memo delete failed with "column memo_id does not
exist" (Postgres) / the SQLite equivalent - exactly what was reported
after upgrading a running instance.

Revert postgres/sqlite 0.32/00 to its originally-shipped content (MySQL's
0.32/00 is untouched: it was introduced whole in that same commit, so no
MySQL database could have recorded an old-shape version of it) and add a
new, strictly later 0.32/01__poll_definition.sql that actually reaches a
database sitting at 0.32.1: it creates the poll table and rebuilds
poll_vote with memo_id.

Existing poll_vote rows predate memo_id entirely - the schema they were
written under never tracked which memo a vote's poll belonged to - so
there's no data to backfill from; they're discarded (this feature has no
production usage yet). The fix rebuilds poll_vote via DROP+CREATE rather
than ALTER TABLE ADD COLUMN specifically because a schema-version rollback
followed by re-migration is an exercised path in this codebase's own test
suite (TestMigrationSpaceMemberStatusBackfillsActive does exactly this to
an unrelated table) - a database can already have the new poll_vote shape
from LATEST.sql when this file gets replayed, and ADD COLUMN against that
errors, which a first attempt at this fix using ALTER TABLE proved by
breaking that pre-existing test.

Added TestMigrationRepairsPollSchemaAfterInPlaceEdit, which reconstructs
the exact stuck state (drops the poll table, drops poll_vote.memo_id, sets
schema_version to 0.32.1) and asserts the migration heals it and that
deleting a memo with a pre-fix poll_vote row no longer errors.

Verified against the exact real-world scenario: built the pre-fix binary
(commit e59f859), initialized a database with it (creating a poll_vote row
under the old schema, schema_version 0.32.1), then ran the fixed binary
against that same data directory. The migration log shows exactly the new
0.32.2 file applying (0.32.1 correctly skipped as already-applied), and
deleting the old-schema memo - previously the exact failure - now
succeeds. Full go test ./... passes (SQLite; Postgres/MySQL migrations
could not be exercised directly - no Docker daemon for testcontainers in
this sandbox - reviewed by close reading instead).

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_016UZX8r5o3xdW8uKDTQv6Mb

bug: Fix the secuirty issue

Small fix for database

no need for this file.

hashes update.

No backward compatibility needed - this feature hasn't shipped. Replaces
JSON as the sole format for the ```poll fenced Markdown block on both
sides:

- Frontend: parsePollDefinition (types.ts) now parses with the `yaml`
  package instead of JSON.parse; CreatePollDialog serializes with
  YAML.stringify instead of JSON.stringify, producing exactly the target
  block shape (id/question/type/options as a plain mapping, options as a
  block sequence).
- Backend: poll_definition.go's rawPollDefinition struct tags switch from
  `json:"..."` to `yaml:"..."`, and findPollDefinitionInContent unmarshals
  with gopkg.in/yaml.v3 (already a direct dependency) instead of
  encoding/json.

Everything the task asked to keep intact is untouched: the nested voting
route (/api/v1/memos/{memoUid}/polls/{pollUid}/votes) and
EnsurePollBinding's memo-authorization flow, the strict pollUIDPattern
UUID regex, and deletePollDataByMemoIDsTx's user/memo-cascade cleanup
(store/db/{sqlite,postgres,mysql}/user_delete.go - this is the actual name
of the cleanup function the task referred to as
deletePollVotesByVoterTx; it deletes both poll and poll_vote rows by
memo_id, not by voter, and was not touched by this change).

While preserving pollDefinitionHash's canonical/injective requirement,
switching formats surfaced a real pre-existing bug worth fixing here:
the hash wrote a bare NUL byte as a separator between options with no
length prefix, which is not actually injective - an option string that
itself contains a NUL byte reproduces that exact separator byte sequence,
so e.g. options ["ab", "c"] and a single option "ab\x00c" hashed
identically. YAML permits arbitrary control characters in a quoted
scalar, so this was reachable from memo content, not just internal data,
and a collision here would let an edited option set silently keep votes
that should have been reset as stale. Replaced the separator with a
fixed-width big-endian length prefix per field (Type and each Option),
which is unambiguous regardless of content - this is what "canonical/
injective serialization" actually requires, and is why option identity in
this hash was still separator-based rather than delimiter-free lengths
even in the JSON version's design intent.

Added tests for both: server/router/api/v1/poll_definition_test.go covers
YAML parsing (block/flow style, defaulting to single-choice, UID
mismatch, malformed YAML, too few options) and the hash property directly
(formatting-invariance, the concatenation collision the length prefix
fixes, and the NUL-byte-smuggling case specifically) - the NUL-smuggling
test fails against the pre-fix hash implementation, confirming it
exercises the real bug. web/tests/poll-definition.test.ts covers the
same parsing surface from the frontend side.

Verified end to end against a live server: created a memo whose content
is exactly the target YAML block example, confirmed it round-trips
through save untouched, voted through the nested route, read back
matching tallies, and deleted the memo (exercising the poll/poll_vote
cascade cleanup) without error. Full go test ./... and the full frontend
vitest suite (1127 tests) both pass.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_016UZX8r5o3xdW8uKDTQv6Mb

…leanup

Two gaps found while rebasing the YAML-format refactor onto commits pushed
directly to this branch in parallel:

1. store/migration/postgres/0.32/01__poll_definition.sql was deleted
   ("no need for this file."). That file is the actual fix for the
   "column memo_id does not exist" bug reported earlier on this branch: a
   Postgres database that already recorded schema version 0.32.1 from the
   original poll_vote-only migration has no path to the poll table or
   poll_vote.memo_id without it, since editing the already-applied 0.32/00
   file in place (what an earlier commit had done) has no effect on a
   database that already ran it - schema version tracking is a monotonic
   per-version marker, not a per-file-content hash. Deleting 0.32/01
   silently drops GetCurrentSchemaVersion's computed target for Postgres
   back to 0.32.1 too, so Migrate() sees current == target and skips
   migration entirely - such a database would stay stuck exactly at the
   bug's original broken state. Restored the file (byte-identical to what
   was verified end-to-end in this branch's earlier fix: built the pre-fix
   binary, created a poll_vote row under the old schema, then ran the
   fixed binary against that same data directory and confirmed both the
   migration and the previously-failing memo delete succeed).

2. deletePollVotesByVoterTx (added to store/db/postgres/user_delete.go in
   a parallel commit) was Postgres-only. It's a real, distinct gap from
   deletePollDataByMemoIDsTx: that function only cleans up poll data for
   memos the deleted user owns, so a vote the user cast on someone *else's*
   memo survives deletion as a poll_vote row whose voter_id no longer
   resolves to any user. Mirrored the same function (with an explanatory
   comment) to store/db/{sqlite,mysql}/user_delete.go, matching this
   codebase's established pattern of giving every driver equivalent
   treatment. Extended TestDeleteUserCleansRelatedData
   (store/test/user_delete_test.go) with exactly this scenario - the
   deleted user and a peer both vote on the peer's memo poll - and
   confirmed only the deleted user's vote is gone; verified the assertion
   actually exercises the fix by reverting the SQLite half of it locally,
   watching the test fail, then restoring it.

Full go test ./... and frontend tsc --noEmit pass.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_016UZX8r5o3xdW8uKDTQv6Mb

Just updating.