/triage must render and honour priority:next — Aedan's prioritised queue nf-0ac ← Beads

Twinned from https://github.com/cfsh/ninefold/issues/698 by tools/beads/import_github.py's reconcile pass.

New label priority:next: @aedanpope has prioritised this chunk; take it before anything unlabelled. First use is #686 (implement design 005).

It is a label rather than a line in the board body deliberately — #398 says of itself *"regenerated by /triage from live GitHub state each round — labels, CLAIM markers and open PRs are the source of truth, and this body is a cache of them"*, so a hand-written priority in the body is erased by the next round. Labels are what triage regenerates *from*, so they survive it.

What /triage should do with it:

1. Render it — surface priority:next chunks at the top of the Chunks table, not sorted in with the backlog.
2. Honour it — assign a prioritised chunk before an unlabelled one when a session frees up.
3. Never set or clear it. It is @aedanpope's signal. Triage reads it; only he writes it. (The CTO applies it when he says so in chat, as here.)
4. ⚠️ Priority is not readiness. #686 is prioritised *and* deliberately blocked behind the probe_gate stack (#653 #662 #665 #680) — he said so himself: *"I know we are waiting for the s0 probe fixes."* A prioritised chunk with an unlanded dependency should still show as prioritised and still not be assigned.