bug: Fix the secuirty issue - #3

…and pin votes to a stable definition

Addresses a pre-merge security review of the poll feature. Three gaps:

1. Poll access was authorized by nothing but a client-supplied poll UID -
   any authenticated (or, if instance policy allowed it, anonymous) caller
   could read or vote on a poll embedded in a memo they had no access to,
   since the UID alone carried no binding to the memo's visibility or
   creator. The REST routes are now nested under the owning memo
   (/api/v1/memos/{memoUid}/polls/{pollUid}/votes) and every request runs
   through the same server/access read-authorization used for reads
   elsewhere (visibility, creator, space membership, anonymous-access
   policy) before touching any vote.

2. MySQL had no poll_vote table at all (it was only ever added for SQLite
   and PostgreSQL), so every poll operation on a MySQL install would fail
   outright. Added store/migration/mysql/0.32/00__poll_vote.sql and the
   matching LATEST.sql section, following this directory's existing
   conventions (AUTO_INCREMENT, UNIX_TIMESTAMP() defaults, inline KEY
   clauses - MySQL has no CREATE INDEX IF NOT EXISTS, unlike SQLite/
   Postgres, so indexes have to be inline to keep the migration replay-safe).

3. A poll's definition (question/options/type) lives in the memo's
   Markdown, so nothing stopped an edit from reordering or relabeling
   options while old votes silently kept pointing at stale indices, or a
   ```poll block (and its UID) being copied into a second memo to share or
   hijack votes. Added a `poll` table binding each UID to the single memo
   that first established it (store.EnsurePollBinding): a UID surfacing
   under a different memo is rejected (ErrPollMemoMismatch, HTTP 409); a
   changed option set/choice-mode under the *same* memo (detected via a
   hash of type+options, computed server-side from the memo's live content
   by a new Go poll-block parser mirroring the frontend's parsePollDefinition)
   clears the now-stale votes and rebinds rather than silently
   misattributing them - safe because only someone who could already edit
   the memo could have changed its content. poll_vote gained a memo_id
   column so memo deletion cleans up both tables the same way every other
   memo-child table already does in this codebase (explicit app-code
   cleanup in the delete cascade, not FK cascade - SQLite runs with
   foreign_keys disabled here).

Frontend: PollBlock/CodeBlock/MemoMarkdownRenderer now thread the owning
memo's resource name down (mirroring how AnchorLink already gets memoName),
since pollApi.ts's requests are memo-scoped; a poll rendered where no memo
context exists (e.g. MemoPreview's relation-embed card) shows statically
with voting disabled rather than erroring. types.ts also now validates a
poll id is uuidv4-shaped, matching a mirrored check server-side, since it
flows unmodified into a URL path segment and this package's SQL layer.

Verified: full go test ./... (including new EnsurePollBinding/cascade
coverage) and the full frontend vitest suite pass; a live end-to-end smoke
test confirmed a non-owner is denied read/vote access to a private memo's
poll (403), anonymous access is denied (401), a copy-pasted poll UID under
a second memo is rejected (409), and editing a poll's options clears its
prior votes. MySQL/PostgreSQL migrations could not be exercised directly
(no Docker daemon in this sandbox for testcontainers) - reviewed by close
cross-reference against this repo's existing migration conventions instead.

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