fix(launcher): establish the user PATH for a fresh WSL session

[sbracewell64]

Intent

Fix the Windows launcher's fresh-session PATH gap so the harness menu sees user-installed harnesses and defaults to the ruled default (Claude).

firstmate.bat deliberately launches wsl.exe --exec /bin/bash so the launch never depends on the login shell, but bin/fm-wsl-entry.sh never re-established the user-level PATH.
A fresh session therefore carried only the system directories plus Windows interop appends.
bin/fm-launch.sh probes each menu entry with command -v, so every harness installed under the account's private bin directories rendered as "not installed - install " and the Enter default fell away from Claude.

Change

bin/fm-wsl-entry.sh prepends $HOME/.local/bin and $HOME/bin when they exist, before handing off to the launcher.

Those are exactly the two directories the distribution's stock ~/.profile prepends, and every supported harness installer targets ~/.local/bin, so this restores interactive parity as a filesystem fact.
Evaluating a login profile in a non-interactive launch was ruled out deliberately: it would inherit arbitrary side effects, ordering, and failure modes.
Reusing bin/fm-remote-job-lib.sh's remote PATH composer was also considered and rejected, because its non-symlink exclusion is a remote-trust rule that would under-detect a locally symlinked ~/.local/bin - the opposite of the parity this fix owes.

Only existing directories are added, only once, ahead of the system tail in the same order a login shell produces, and nothing already on the inherited PATH is removed or reordered.
firstmate.bat's --exec /bin/bash choice is deliberately untouched: its no-login-shell rationale stands, and the entry script owns environment establishment.

Test evidence

Witnessed red first. With PATH stripped to the system directories, the menu rendered all five entries dim and "nothing is available yet"; the two new cases in tests/fm-wsl-entry.test.sh failed against the unfixed entry script with claude=[NOT-ON-PATH].

New cases, both green after the fix:

• a fresh session resolves harnesses installed in both ~/.local/bin and ~/bin, using a fake HOME and a PATH stripped to system directories;
• the established PATH adds only existing directories, never duplicates one already present, and never invents an absent ~/bin.

End-to-end through the real bridge command:

wsl.exe --cd <repo> --exec /bin/bash ./bin/fm-wsl-entry.sh --print-menu

now renders a menu byte-identical to the interactive bin/fm-launch.sh --print-menu - Claude default restored, Codex available, both Pi-routed entries available with their correct sign-in note, and OpenCode still honestly dim because it genuinely is not installed. That covers every harness the menu lists, not only claude.

bin/fm-lint.sh (ShellCheck 0.11.0, pinned) and bin/fm-doc-audience-check.sh both clean.

CI state - disclosed honestly

This branch was validated through the local no-mistakes pipeline: intent, review, test, document, lint, and push all completed with zero findings.
Two steps did not run and are not evidence of anything:

• rebase, skipped. This is fork-targeted work on the fork trunk; rebasing would have replayed the fork's landing queue.
• ci, skipped. The pipeline first opened a pull request against the upstream repository, where it bundled the whole landing queue and reported a base-branch merge conflict. That upstream pull request was closed as mis-venued, and this fork pull request is the correct venue. The CI step's only finding was that venue conflict, so it was skipped rather than accepted.

Consequently no CI run has examined this head yet. Treat the checks on this pull request as the authority; the local pipeline evidence above is not a substitute for them.

Files

• bin/fm-wsl-entry.sh - establish the user PATH, with the rationale in the script header.
• tests/fm-wsl-entry.test.sh - two new behavior cases.
• docs/windows-launcher.md - operator-facing PATH fact and a troubleshooting line for a harness installed elsewhere.

[sbracewell64]

CI outcome on this head: 12 passed, 2 failed

Both failures are accounted for, and neither comes from this diff.

1. PR must be raised via no-mistakes - fail.
Expected. This pull request was opened by hand after the automated pipeline opened its pull request against the upstream repository, where it bundled the fork's entire landing queue (47 commits, 203 files) and reported a base-branch merge conflict. That upstream pull request was closed as mis-venued and this fork pull request is the correct venue. The local no-mistakes run for this branch completed with intent, review, test, document, lint, and push all clean and zero findings; only the rebase and CI steps were skipped, both for that venue reason.

2. Behavior portable serial 2 - fail.
tests/fm-remote-secondmate-lifecycle-e2e.test.sh: not ok - first inheritance transaction never reached its blocked write.

This is pre-existing on the base commit and unrelated to the launcher change. Verified locally by running that test on both heads:

• at this branch's head a69c8c6 - fails;
• at the base commit ed376cf, with this change absent - fails identically.

The assertion is a bounded wait for a concurrent inheritance transaction to reach its blocked write. This diff touches only bin/fm-wsl-entry.sh, its test, and docs/windows-launcher.md, none of which participate in remote secondmate config push.

The checks that cover this change all pass, including Windows launcher bridge, Lint shell scripts, Repo invariants, Test coverage guard, and the remaining behavior suites.