feat(board): FLY column and free-capacity lines, no process inspection

ORDRE counted pending orders only, so a repo with one order in flight and a
repo with no orders at all both printed 0 - the same digit for two opposite
facts. Measured 2026-08-23: two panes stood open and idle for 45 hours holding
finished orders, with full quota authorised, and no column on the board
reported it.

FLY counts orders/claimed/ - the same queue in its other state, never summed
with ORDRE and never a fourth axis. It does NOT mean a session is alive:
nothing un-claims an order when the claiming session dies, and one order on
the live mailbox had been claimed for 117 hours. The legend denies the
liveness reading in those words, pinned as a check on the legend text.

--plan now names free capacity as ledig_antall=N plus one ledig=<repo>
(<status>) line per repo with nothing owed, no pending order, nothing in
flight, a clean tree, at done or deferred. All four conditions are required:
measured on the real tree, 4 of 17 done/deferred repos were not free. Lines,
never blocks - the plan's second consumer discards a block with no tab=, so a
block would be visible to the operator and invisible to the driver.

Process inspection was considered and refused; the selftest asserts the
absence of pgrep/pkill/lsof structurally with a known-positive control. The
full argument, and the gap left open, are in
docs/2026-08-23-free-capacity-investigation.md.

board-selftest: 259 -> 281 checks, all green. npm test 11/11.

Order 20260823T162951Z-941745020-from-.claude

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Hfbfr8ERC63kuAfWeHYHQb

skills/board/SKILL.md

@@ -20,7 +20,7 @@ description: >-
   user names no repo and no tool — choosing *between* repos is this skill. Not for
   "where were we" inside the current repo: that is this repo's own STATE.md,
   already injected at session start.
-version: "0.28.0"
+version: "0.29.0"
 ---
 
 # board — which repo deserves the next session
@@ -64,11 +64,23 @@ rule exists to stop. The run costs about three seconds.
 | `STATUS` | `planned` / `in-progress` / `blocked` / `deferred` / `done`, or `blocked>X` naming the repo it waits on. `?` means the STATE.md has no board line. |
 | `KOST` | Model/effort for the next step, from the rubric row table in `route.sh` (the `route` skill writes it; this one only reads it). |
 | `INN` | Unhandled inbox: **other repos are waiting on THIS one**. An obligation it owes outward. |
+| `ORDRE` | Pending orders: **authorized work is waiting on this repo**, unclaimed and pickable. |
+| `FLY` | Orders in flight (claimed). Someone TOOK the order — never proof a session is still alive. |
 | `DRT` | Uncommitted files. |
 | `ALDER` | Days since STATE.md last changed — the age of the *plan*. `-` where the repo has none. |
 | `SISTE` | Days since the last commit — the age of the *work*. `-` where the repo has no commits yet. |
 | `NESTE` | First line of the STATE.md next-step block, truncated. |
 
+**`ORDRE` and `FLY` are never summed, and `FLY` is never read as "busy."** They
+are the same queue in two states. Before `FLY` existed, a repo with one order in
+flight and a repo with no orders at all both printed `ORDRE 0` — the same digit
+for two opposite facts, which is how two tabs sat idle for 45 hours holding
+finished orders with nothing on the board reporting it. What `FLY` still cannot
+tell you is whether a session is *running*: nothing un-claims an order when the
+session that claimed it dies (one order on the live mailbox had been claimed for
+117 hours). Say "an order is claimed here", never "a session is working here".
+The board inspects no processes and will not start.
+
 **`INN` never means "this repo is waiting on someone."** It means the opposite:
 messages arrived and were not handled. The mailbox format carries no reply-to or
 thread field, so outbound waiting is not derivable from it at all — `blocked>X` is
@@ -178,6 +190,18 @@ Two things to say out loud when you hand it over:
   command to paste. Name those repos rather than letting the operator discover it
   per tab. Fixing them is the `route` skill's job, in *that* repo — never a side
   quest here.
+- **`ledig_antall=N` and the `ledig=` lines are free capacity, not tabs.** They
+  name the repos that can take NEW work: nothing owed, nothing queued, nothing in
+  flight, clean tree, at `done` or `deferred`. They carry no `tab=` and no
+  command on purpose — there is no next step to start, so the operator decides
+  what to send there. Read them out when the ask is about capacity ("hvem kan ta
+  mer arbeid", "hvor har jeg ledig kapasitet") and whenever the plan is short.
+  `status=done` alone is **not** the same set: on the real tree 4 of 17
+  done/deferred repos were not free. Never derive this list yourself from the
+  table — the engine joins four fields you would have to join by hand.
+- **`fly=N` on a tab block means that repo already holds a claimed order.** Say
+  so before the operator opens the pane. It is not proof a session is live, and
+  it is not a reason to drop the tab — it is a reason to look first.
 
 ### When the day has a subject ("fokusdag")
 

skills/coord-send/SKILL.md

@@ -15,7 +15,7 @@ description: >-
   covers retiring a broadcast that has become wrong or obsolete: "retract that
   broadcast", "that announcement is outdated, pull it", "trekk tilbake kringkastingen",
   "den broadcasten er utdatert".
-version: "0.28.0"
+version: "0.29.0"
 ---
 
 # coord-send — natural-language front door for inter-repo messages

skills/dispatch/SKILL.md

@@ -17,7 +17,7 @@ description: >-
   skill. Not for choosing WHICH repo deserves the next session (that is `board`),
   not for scoring model and effort alone (that is `route`), and not for sending a
   message to another repo (that is `coord-send`).
-version: "0.28.0"
+version: "0.29.0"
 ---
 
 # dispatch — hand a session a task it can actually start on

skills/route/SKILL.md

@@ -14,7 +14,7 @@ description: >-
   the operator names no model and no tool — choosing the model for the next
   session IS this skill. Not for choosing which REPO gets the next session:
   that is the `board` skill.
-version: "0.28.0"
+version: "0.29.0"
 ---
 
 # route — what the next session should run with