feat: multi-election periods via per-topic election tags

Docs: Add Assets concept page and examples

Implements the election frames of the Period Detail design handoff
(claude.ai/design 'Period Detail.dc.html', frames 1/3/6).

Each race on an election ballot now renders as its own card — E.0N chip,
name, seat count and candidate count — instead of a bare h3 over a flat
list of topic cards. What sits inside depends on the state:

- scoring (active, eligible, simple) — one CandidateBallotCard per
  candidate: avatar, statement, and Support/Veto/Abstain chips that tint
  the card once picked. A legend band prices the chips (+1/-1/0) and a
  footer tracks 'n of m candidates scored'.
- advanced — the existing TopicVoteCard allocation inputs, unchanged.
  Splitting power across the three options is still a valid ballot, and
  single-choice chips cannot express it.
- read-only (logged out, ineligible, ended) — ElectionStandings: the
  candidates ranked by net score with 'in seat range' pills and a
  seat-cutoff note, replacing per-candidate tally bars that ranked
  nothing.
- upcoming — the plain option list, inside the same card shell.

Labels come off the on-chain options via classifyOption rather than
being hardcoded, so a period seeded before the Veto rename still reads
'Against' in its own legend and standings.

Grouping is presentation only: every card stays keyed by on-chain topic
index, so ballot state and the vote() payload are untouched.

Election candidate ballots are Support / Veto / Abstain instead of
Support / Against / Abstain, across the Manage UI that writes the
on-chain options, the results/scoring copy, the docs pages, the
Storybook fixtures and the sample-data seeders.

ElectionCandidate.against is renamed to .veto to match.

utils/vote.ts is untouched on purpose: its NO_RE already matched both
'against' and 'veto', so periods already on chain with Against labels
keep tallying and colouring correctly alongside new Veto ones.

A period runs elections when its body carries `elect`; each candidate names its
race through its own topic body's `e`. The results page understood that, and so
did the operator UI — the ballot and every period summary did not. A voter
meeting a two-election period saw seven undifferentiated "topics" with no way to
tell which seat anyone was standing for.

"Candidate" is a presentation word for a topic in an election period: the
contract, the ABI and every SDK handle stay `topicIndex`, so this is a copy
change, not a rename. utils/periodTerms.ts holds the noun and the count label in
one place — the two existing `isElection ? … : …` ternaries had already drifted
apart (the add-candidate form said "Add topic" in its disconnected state).

Ballot (VotePeriodDetail):
- candidates group under per-race headings via the SDK's groupCandidates,
  matching the results page. Ordering only: the state arrays, buildVotes() and
  the vote() payload stay flat and keyed by on-chain topic index.
- candidates whose `e` is missing or names no declared election are dropped by
  groupCandidates but still rendered, in a trailing section. The contract
  requires every topic row to carry the voter's full power, so leaving one off
  the ballot would make the period unvotable.
- the T.0N ordinal chip is suppressed for candidates — it would number straight
  through races that are ranked separately.
- the two near-identical "View Ranked Results" blocks (one right-aligned, one
  not) become one strip that also names each race and its seats.

Summaries now read "2 elections" / "5 candidates" / "3 topics": the period list
rows and column header, both heroes, the detail and results meta lines, the
sidebar info card, and the operator table. All of them already fetched the
period body except the operator table, which gains one read per row and a
TODO(perf) naming the batched reader that would collapse it.

Manage:
- assignment warnings move onto the page. They existed only inside the
  Mark-ready dialog, so an operator who never opened it had no idea a candidate
  was running in no race — and once the period is ready and a vote lands, the
  topic set is frozen and it can no longer be fixed.
- the fix-ability message keyed off canEdit, which folds in `!!sdk`, so a
  disconnected visitor was told the period was "no longer editable" when it was
  simply not connected. Split into `editable` vs `canEdit`.
- the remaining unconditional "topic" strings (remove-confirm, body dialog,
  placeholders, the disconnected add form) go through the shared terms.

Docs: /docs/periods gains an elections section and the glossary gains Election
and Candidate. Both spell out the rule that surprises people — you cast on every
candidate, including races you don't care about, and Abstain is how you sit one
out.

Also: deploy-sample-data declared `{ t: 'EAC', s: 1 }` while its own prose,
comments and console output all described a 2-seat treasury committee;
detailScenario accepted `elect` but hardcoded its topics, so the one election
story flagged an election over two untagged reward-policy topics. Both fixed,
plus multi-election detail stories and election rows in the list fixture.

Typecheck, lint and prettier are clean and the two ballot play-tests still pass.
Verified against localnet sample data (the active two-election period 2),
including a throwaway draft period carrying an untagged candidate to exercise
the manage callout and the trailing ballot section.

The nightly algod now emits the pqsig key in SignedTxn. The previously
pinned SDK (2026-06-24) predates the post-quantum signature types, so
go-codec rejected the unknown key and block import failed with
"no matching struct field found when decoding stream map with key pqsig".

The nightly algod now emits the pqsig key in SignedTxn. The previously
pinned SDK (2026-06-24) predates the post-quantum signature types, so
go-codec rejected the unknown key and block import failed with
"no matching struct field found when decoding stream map with key pqsig".