Building on top of an old dist/ can fail with a missing dist/chunks
module. Document the clear-and-retry workaround next to the build
acceptance criterion so contributors in existing clones aren't blocked.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

TCE-72. The `test` job is the ONLY gate on test -> build -> provenance ->
cosign-sign -> pypi-publish, and it cannot see the thing that matters.

WHY IT COULD NOT FAIL FOR THE RIGHT REASON

It installs dev = ["pytest>=8"]. It never builds the pinned Falcon library,
never sets FALCON_DET1024_LIB, never sets TRELYAN_REQUIRE_KAT. So every lib-gated
test skips. Its anti-vacuity counter is

    grep -cE "^tests/.* (PASSED|FAILED)" pytest.log

which BY CONSTRUCTION CANNOT COUNT SKIPPED, and the ~50 lib-independent tests
clear its floor of 15 on their own. Measured in exactly that environment: 50
passed, 19 skipped, counter = 50. The counter is blind in both directions --
DELETING the 13 lib-gated tests outright would not change it.

So SLSA Build-L3 provenance and a Rekor-logged cosign signature were produced
without anything having verified signature byte-identity against the
on-chain-accepted goldens, runtime private-key zeroization, or worker-stdout
containment. To a downstream consumer "signed and attested" reads as vouched
for; it vouched only for where the bytes came from.

THE FIX: require ci.yml's byte-identity KAT to be green FOR THIS TAG

Cross-workflow `needs:` does not exist, so the new require-signature-kat job
asks the checks API directly: did the job that builds the PINNED Falcon source
and re-signs the committed goldens on Linux, macOS and Windows succeed for this
exact commit? build now needs [test, require-signature-kat].

Scoped to signature-kat on purpose rather than "every check green":
contract-drift is red by design until the redeploy, and coupling releases to
that is the maintainer's policy decision, not something to smuggle in via a gate.

REAL DATA CHANGED THE IMPLEMENTATION TWICE, which is the point of testing it

My first version counted legs and failed on any non-success. Run against a real
commit it was WRONG on both counts:

  * SIX legs, not three. A commit both pushed and open in a PR gets two workflow
    runs, so the 3-OS matrix appears twice.
  * one macos-latest leg carried conclusion "failure" from the EARLIER run while
    the later one succeeded. "Any non-success blocks" would have refused a
    release over a stale result -- as wrong as passing on nothing.

So it now reduces to the LATEST result per leg (sort -r on ISO-8601 started_at,
then first-wins per name), and separately requires all three OS legs to be
PRESENT -- a leg that was never scheduled is not a pass, and counting rows alone
would accept one green leg as though it were three.

Also: `gh api --slurp` is rejected together with `--jq`, so the filter runs
per page and must not group; grouping is done with sort+awk, which additionally
means this needs no external jq on the runner.

The `test` job now counts and prints SKIPPED, and its comment states plainly
what its counter cannot see and where that assurance actually comes from.

VERIFIED

  * the gate extracted FROM release.yml, run against live GitHub check-run data:
    stale macos failure correctly superseded, 3 legs green, EXIT=0
  * all four failure branches exercised with synthetic inputs:
      one leg FAILED        -> EXIT=1
      a leg MISSING         -> EXIT=1 (names the OS)
      no legs at all        -> EXIT=1 (says CI never ran on this commit)
      one leg still PENDING -> EXIT=1
  * bash -n clean; release.yml parses; needs chain confirmed

NOT VERIFIED HERE: no tag was pushed, so the job has not run inside Actions.
The gate logic is verified against the real API from this machine; the workflow
wiring is verified only by parsing.

- The registry becomes an MBR vault. `vote()` ends with `checkNeedMBR()` subroutine: if the instance app account is at or below its minimum balance, it inner-calls the registry's new `requestMBR`, which pays it `mbrTopUp` (new global, 5 A, settable via `setMBRTopUp`). Users never pay vote-record MBR, and instances no longer need hand-funding.

- Post-condition, not a threshold. The AVM updates `min_balance` the instant a box is allocated but enforces the requirement only after each (outer) transaction, so the account may sit underwater mid-execution as long as the top-up lands first. However, MBR do is enforced between intermediate states of a group transaction, so a sibling payment later in the same group would be too late.

Nits: `checkNeedMBR()` could sit in more than one place:
- periodVoteCache is always an overwrite, so the call could go before it
- on a re-vote the record write is an overwrite too, so the call could be skipped

Left plain at the end for clarity; the saving would be a handful of opcodes. What is not flexible is that it must stay after the vote record write - that write is the allocation it repairs.

pnpm audit --audit-level=high was failing on:

- nanoid <3.3.18 (GHSA-2v37-7h3g-55p8, "custom generators can loop
  indefinitely when size is zero") -> 3.3.17 bumped to 3.3.18

nanoid is only in the tree transitively via postcss (>vite>vitest etc.),
whose ^3.3.11 range already admits the fix, so this is a lockfile-only
bump with no override — same as the previous 3.3.16 -> 3.3.17 bump.
3.3.18 was published 2026-08-07 and is now past the workspace
minimumReleaseAge, so no exclude is needed either.

pnpm install --frozen-lockfile and pnpm audit --audit-level=high verified
locally (0 high; 4 low / 5 moderate remain, below the threshold).

- `/manage/period/$periodId` now has two faces. Edit is opt-in via `?mode=edit`; View is the absence of that param, and `validateSearch` normalizes any other value to View. A View/Edit toggle sits in the header, hidden when there is no wallet or the period is frozen.

- Every write affordance now gates on one flag: `showEditControls`, defined as connected SDK + `mode === 'edit'` + `editable`. `editable` now means the period is not frozen, based on readiness and votes. This replaces the previous status-based definition.

- Dropped the `status === 'upcoming'` condition. The contract's `editPeriod` only asserts operator, `!ready`, and `end > start`, so a draft whose voting window is active or has passed is still editable on chain.

- A ready period with no votes cast is still editable because it can be reverted to draft. It keeps edit controls live in Edit mode and shows a warning that changes will fail until it is reverted. The contract, not the UI, rejects those writes.

- Added `src/utils/periodEditing.ts` with shared `periodHasVotes` and `periodFrozen`, used by the list and detail page. A ready period with votes cast is frozen, so it gets no Edit affordance and no View/Edit toggle.

- Manage periods list: the title cell links to View, and the actions column holds a single button per row: Edit, or View for a frozen period.

- Misc: the Upcoming status chip no longer uses `bg-accent`; it now uses a custom soft pink so it is visually distinct from Ended. This intentionally uses a Tailwind color outside the design tokens because it only appears in the operator-only Manage UI.

The pink Upcoming chip was not operator-only: `PeriodStatusBadge` also renders on the period detail, results and account pages. Back on design tokens, reusing the tones `PeriodStatusTag` already had, so a status looks the same wherever it appears. The two badges are merged, with union props so neither list rows nor detail pages recompute a status they already hold.

feat: enforce Abstain as the last topic option