bc-68ou.15: B7e-unlanded — Where does this exist, if it is not on main yet

[mordam]

Adds b7e-unlanded (bc-68ou.15), a b7e-* skill command that answers "where does this
symbol or path exist, if it is not on main yet, and what does it say there" — the
question four sessions (bc-fh0sz, bc-gdub, bc-khoe.4, bc-khoe.30.14) each answered by
hand with six-plus git/gh calls, one of them losing a call to a shell gluing a ref
and a path together wrong (git show "${B}:test/panes.mjs" → fatal: ambiguous argument 'worktree-releases-view-khoe7est/panes.mjs').

lib/unlanded.js carries the search: git grep/cat-file/diff against main and
every worktree-* branch this checkout knows about, plus gh pr list/pr view for
each hit's PR number, state, merge state and tip commit — best-effort, same as
lib/prior.js. Two design choices worth flagging for review: (1) a hit on main
short-circuits the search rather than also walking every branch — this repo carries
~350 worktree-* branches, and once something has landed every branch cut afterward
inherits it in its tree, so an unconditional sweep on an already-landed symbol
(viewHop, tested live) took over two minutes of gh pr list calls for nothing new.
--all overrides the short-circuit for a caller who wants to know about an unlanded
change on top of something that already merged. (2) ${ref}:${path} (git's own
object-spec syntax, needed for cat-file -p) is built as a plain JS template string and
handed to execFile as a single argv element — no shell in between, which is why the
bc-khoe.30.14 gluing bug cannot recur here structurally, not just by convention.

Wired per the checklist bc-dgx7.1's debrief and the memory store describe: bin
registered in both package.json and package-lock.json's packages[""].bin
(alphabetized, inserted between b7e-triage/b7e-watch), Bash(b7e-unlanded:*) added
to DEFAULT_TOOL_LIST in lib/toolbelt.js and classified read in lib/grants.js
(the second registration test/grants.mjs fails closed on if it's missed), a README
section, and test/b7eunlanded.mjs.

Left for the reviewer's judgement: the --show flag is accepted but is a no-op (path
mode already defaults to printing the whole file, which is what the bead's own
acceptance criterion for public/releases.js asks for without naming a flag) — I kept
it only because the bead's own "Takes" example uses it, documented as "already the
default" in --help. Also, symbol search across the full worktree-branch list (the
"not on main" case) took ~14s against a real 345-branch tree in manual testing —
tolerable for what it replaces, but a --branch/--pr pin is much faster when the
caller already knows where to look.

Tests: Full gate (bin/b7e-gate, 6-way parallel over all 421 test/*.mjs + scripts/selftest.mjs + scripts/test-swap.js) run twice in the fresh worktree: first cut failed on a fresh worktree's missing node_modules (unrelated to this change — Cannot find package 'yaml'), fixed by symlinking node_modules from the main checkout and running scripts/vendor.js; the re-run passed all 421 suites, 0 failures. Also ran test/b7eunlanded.mjs (16 checks, replaying the bead's three acceptance criteria plus the main-short-circuit/--all/--branch/--pr/--diff/--json paths), test/grants.mjs, test/lockfile.mjs, test/anchors.mjs, test/loadorder.mjs individually before the full gate.

Files changed — 8 files · +790 −0 · against `main`

lib/unlanded.js       +301 −0
test/b7eunlanded.mjs  +294 −0
bin/b7e-unlanded      +123 −0
README.md             +61 −0
lib/toolbelt.js       +8 −0
lib/grants.js         +1 −0
package-lock.json     +1 −0
package.json          +1 −0

---

Opened by a beadcause worker session on bc-68ou.15 — b7e-unlanded — Where does this exist, if it is not on main yet — and what does it say there. It merges itself once the checks report; merging is what closes the bead. If this is still open, something stopped that, and the reason is on bc-68ou.15 and in Adam's inbox.

bead: bc-68ou.15

[mordam]

A beadcause worker opened this and does not merge its own work. It is on the merge queue as bc-lq91q.

[mordam]

The beadcause merge queue tried to merge this and could not: it has been tried 3 times and stopped at the same place each time. the branch still conflicts with main and no resolver is on it any more — the window that was opened on it ended without making it mergeable, so this one is yours to settle. Tried 3 times — that was the last. It is Adam's call now — see bc-lq91q.