v0.1.13 everywhere: version badge, pin examples, landing page, release request

[navbytes]

One change landed since v0.1.12 (#157).

C41 — the keymap overlay runs what it teaches. Alt+? already drew
every binding grouped and labelled, F9 already gave it a / type-ahead over
both columns, and F1 already made each row declare the actions it
documents rather than a compiled-in spelling. That is a command palette in
every respect but one — it could not press the button. This is that one
keystroke: while the filter is open, ↵ runs the row under the cursor.

No new chord, no new mode, no second list. A separate palette on its own
chord was the obvious build and it was the wrong one: a second list of
commands is a second thing to keep true, and this table is already the one
roost sweeps against Action for coverage. Un-filtered, C15's overlay is
unchanged — any key dismisses it, no row is marked. / is what turns it
into a picker, and that is the state whose title and hint bar advertise ↵.

A row is runnable only when it documents exactly one action, and the
rows that resist are precisely the ones nobody would drive this way. A
multi-action row — Family (Alt+←↓↑→, Alt+Shift+←↓↑→) or a multi-action
Chords (previous / next tab) — is a direction set: there is no answer to
which one ↵ runs, and picking one would be the wrong feature anyway, since
those are the chords you press five times running and a palette that
performs one step then closes is worse than the chord it stands in for. The
ambiguity and the uselessness coincide, so one rule covers both. What
survives is what a palette is for: flip split, cycle layout, zoom, undo,
rename, mark/pull, the raw/float/feed/roster toggles.

The cursor indexes commands rather than drawn lines, clamps at both ends
rather than wrapping (C27's rule — the row it lands on is one keystroke from
running), and is read from the flat table before help_layout pours it
into one column or two, so a resize under an open palette cannot move what
↵ points at. Editing the query resets it to the first command, which is
what makes the core gesture land without an arrow key.

The mark is ❯ — C14's picker marker and C27's roster marker in its third
overlay — drawn into the leading space help_key_prefix already opens every
key column with, so it costs no width. A marker column of its own would
widen every row by one, re-tripping elide_key and moving HELP_COL_FLOOR:
the accounting C38 and C39 each had to correct once already.

Found while building: walking the cursor back to the first command left the
view scrolled to row 1, pushing the PANES heading off the top so the
dialog opened on a bare chord. Scroll-up now keeps one line of context above
the cursor.

The landing page's key count is unchanged at 19 — C41 adds no chord, so only
what the Alt+? row promises moves.

Touching .github/release-request dispatches Release, which builds four
targets, creates the v0.1.13 tag from Cargo.toml itself, and publishes
with SHA256SUMS.txt.

Verified before cutting: 992 unit tests and all 35 integration binaries
green, cargo +1.96.1 clippy --all-targets -- -D warnings and fmt --check
clean.

Not done: the design-supervisor audit CLAUDE.md requires for src/ui/**
changes — this session was configured not to launch agents.

Note for after the merge: HOMEBREW_TAP_TOKEN is still unset, so release.yml
will skip the tap sync again (it did for v0.1.10, v0.1.11 and v0.1.12). The
formula needs the usual hand-sync —
RENDER_ONLY=1 RELEASE_TAG=v0.1.13 scripts/update-homebrew-formula.sh,
PR'd to navbytes/homebrew-tap.