fix(launch): stop the classifier recursing through cue's own shim

[NagyVikt]

The bug

The skill/profile classifiers spawned the bare name claude, which on any machine
with cue's shims on PATH (the default — rcSnippet pins them with
fish_add_path -p) resolved to exec cue launch claude "$@". Back inside
launch.ts, the CUE_SMART_SUBSET fold turned that child's own argv into the
next classification prompt, which spawned another classifier, which folded ITS
argv, and so on.

Measured live before the fix:

Prompt template repetitions in one classifier's argv	10
Command line length	67 KB
Concurrent classifier processes	7
Resident memory for those 7	~2.9 GB

Scope correction (from self-review): MAX_LAUNCH_DEPTH = 3 (launch.ts:1579)
already bounds process nesting through the CUE_LAUNCHING counter, so this was
never unbounded recursion. The 10 repetitions are of the prompt template inside a
single argv, and the 7 concurrent processes came from several sessions launching at
once rather than one 7-deep chain. This is a waste bug, not a runaway. The
memory figures above are unchanged.

Why it wasn't caught

CUE_BYPASS=1 was already set on the spawn, and the docstring claimed it made the
shim "transparent". It never did — the only reader was launch-loader.ts:160,
where it suppresses a spinner.

The fix

Two independent guards; either alone breaks the loop.

• launch.ts parse() — refuses the CUE_SMART_SUBSET argv fold under
  CUE_BYPASS, making the flag mean what the classifier already assumed. An
  explicit --subset still wins, so deliberate overrides are unaffected.
• classifierBinOrder() — resolves the real binary first, keeping the bare
  name only as a fallback. A classification no longer boots cue launch at all,
  which also removes a full process boot from every launch's critical path.

Known gap, deliberately not fixed here

CUE_BYPASS is documented in docs/launch.md:207 and docs/shell-install.md:77-82
as "exec the real binary directly; no resolve, no materialize, no profile" —
and nothing implements that. This PR adds a second, narrower reader rather than
implementing the contract, so CUE_BYPASS=1 claude --version still runs the full
pipeline. Widening it here would smuggle a behavioral change into a memory fix, so
it is noted in-code and left as a follow-up.

Verification

• bun run typecheck — clean.
• bun run lint — 7 warnings, all in files this PR does not touch.
• Full suite: 33 failing on this branch, 33 on origin/main, sets byte-identical.
  All 33 pre-existing. (liedetector-tag-density.sh > accepts every step of the 5-point raster appeared in one branch run and vanished on re-run — flaky on both
  sides, absent from the compared pair.)
• New tests: 4 for classifierBinOrder (real-binary-first, shim-skipping, fallback,
  no duplicates), 2 for the parse guard (bypass suppresses fold, explicit --subset
  unaffected).
• Behavior preserved on a real machine — CUE_SMART_SUBSET=1, no CUE_BYPASS:
  claude -p "fix the checkout bug" → subset "-p fix the checkout bug".
• Recursion cut — same env plus CUE_BYPASS=1 and a classifier argv → subset null.
• classifierBinOrder()[0] → /home/deadpool/.local/bin/claude while
  which -a claude still lists the shim first.

🤖 Generated with Claude Code

[NagyVikt]

Review — /code-review

Decision: APPROVE (0 CRITICAL, 0 HIGH blocking) — after the three findings below were applied in 2501d555.

Author and reviewer are the same person here, so the findings are recorded in full rather than waved through.

CRITICAL

None.

HIGH

None blocking. One structural gap found and deliberately deferred:

CUE_BYPASS does not honour its documented contract. docs/launch.md:207 and docs/shell-install.md:77-82 both promise CUE_BYPASS=1 claude "execs the real binary directly; no resolve, no materialize, no profile". Nothing in src/ implements that — before this PR the only reader was launch-loader.ts:160, which suppresses a spinner. This PR adds a second, narrower reader, so CUE_BYPASS=1 claude --version still runs the full pipeline.

Deferred rather than fixed: implementing the full bypass is a behavioral change that does not belong in a memory fix. Noted in-code in claude-classifier.ts and filed as a follow-up.

MEDIUM

The original PR description overstated the mechanism. It read as 10 process levels. MAX_LAUNCH_DEPTH = 3 (launch.ts:1579) already bounds process nesting via the CUE_LAUNCHING counter — the 10 repetitions were of the prompt template inside a single 67KB argv, and the 7 concurrent processes came from several sessions launching at once. This is a waste bug, not a runaway. Measured memory unchanged. → Corrected in the PR body and in both source comments.

LOW

• expect(order).not.toHaveLength(0) asserted nothing given the line above it → replaced with an exact toEqual([realBin, "claude"]).
• docs/launch.md / docs/shell-install.md still describe the unimplemented full-bypass behavior → rolled into the follow-up.

Validation

Check	Result
Type check	Pass
Lint	Pass — 7 warnings, all in untouched files
Tests (targeted)	Pass — 31/31
Tests (full suite vs base)	Pass — 33 failing both sides, sets byte-identical, zero new failures
Behavior preserved	CUE_SMART_SUBSET=1 + no bypass still folds -p to a subset prompt
Recursion cut	+ CUE_BYPASS=1 and classifier argv → subset: null

Note on the review check

This PR's review GitHub check reports skipping — no automated review ran. This review was invoked manually via /code-review. Worth fixing separately: a gate that reports "skipping" reads as green and is how unreviewed changes have landed before.