ccs bare-name fix: LIVE-VERIFY on lezama + guard the latent ~/.bash_profile condition

FIX ALREADY LANDED, THIS ITEM IS THE UNCLOSED HALF. sh.git 2e6753c (+138db6b cosmetic): ccs.sh v5.34 exports PATH="$SCRIPT_DIR:$PATH" right after SCRIPT_DIR is set; ccs-tmux.sh v1.9 sets CCS_CMD="$SCRIPT_DIR/ccs.sh ...". Ruled by pm-llmmsgsrv-cc 2026-08-19: both hunks required, prepend not replace. All 3 hosts pulled, trees clean. ORIGINAL DEFECT (Elazar-reported 2026-08-19 23:16): `sshlezama bin-lezama-cc` printed "ccs-tmux.sh v1.8 / C Claude Code / [exited]" and dropped the connection. Cause: sshlezama.sh:188 runs `ssh -t lezama "bash -lc ..."` = NON-INTERACTIVE LOGIN shell. ~/.bashrc returns at its non-interactive guard before adding ~/.local/bin, AND lezama has a ~/.bash_profile, so bash login reads that and SKIPS ~/.profile:25-26 - the only remaining place ~/.local/bin is added. Result: bare `ccs` (ccs-tmux.sh:74) unresolvable -> exit 127 -> bare [exited]. Second hop ccs.sh:383 `exec claude` was also bare, so fixing only the first converts "127 at ccs" into "127 at claude". ITEM 1 - LIVE VERIFICATION, 0/3 AND ONLY LEZAMA CAN SUPPLY IT. Static-verified on 3/3 hosts (both hunks present, :167 export BEFORE the :398 exec, bash -n clean). Live-verified on 0/3. NO fresh agent spawn has run end-to-end through sshlezama -> agent-attach.sh -> ccs-tmux.sh -> ccs.sh -> exec claude since the fix. Whey and venus CANNOT supply this proof and must not be counted as if they could: neither reproduced the bug (both resolve ccs and claude pre-patch via ~/.profile), so a passing spawn there exercises a path that was never broken. lezama is the only host where the before-line is the actual failure. MUST BE A NEW SESSION, NOT AN ATTACH - attaching succeeds on an already-open inode and proves nothing. Acceptance: `sshlezama bin-lezama-cc` from whey spawns a working session. Until then the fix is reasoned-correct, not demonstrated-correct. ITEM 2 - THE LATENT CONDITION IS UNGUARDED ON WHEY AND VENUS. Measured, all 3 hosts, neutral cwd, `env -i HOME=$HOME bash -lc`: lezama ~/.bash_profile EXISTS -> login SKIPS ~/.profile -> ccs and claude UNRESOLVED (the failure) whey ABSENT -> falls through to ~/.profile:25-26 -> both resolve venus ABSENT -> same -> both resolve Whey and venus pass because of a file that does NOT EXIST. Not a property anyone chose, so not one anyone maintains: `touch ~/.bash_profile` on either host - installer, prompt tweak, anything - silently kills every launcher on that host with a bare [exited] and nothing announces it. v5.34 covers the launcher path specifically; any OTHER bare-name consumer of a login shell on those hosts has the same exposure and no guard. Deliberately NOT fixed by patching lezama dotfiles - that would make all 3 green and leave the code as broken. Recorded by pm-llmmsgsrv-cc. Open: whether a host-check should assert ~/.local/bin present in `bash -lc` PATH (outcome-keyed, the better test) rather than assert ~/.bash_profile absent (mechanism-keyed). CAUTION FOR WHOEVER WRITES THAT CHECK: the default login PATH ending in `.` is LEZAMA-ONLY - venus and whey do not have it. A check written to dodge the resulting `./ccs` artefact would encode a condition 2/3 of the fleet lacks. Probe from a NEUTRAL CWD; correct everywhere, costs nothing. LANE: ccs.sh / ccs-tmux.sh are launcher wrappers = pm-llmmsgsrv-cc only, per CLAUDE.md. bin-* agents diagnose and measure, do not patch. Item 2 host-check is nw lane, and nw-venus-cc is DARK (bin-venus-cc holds aro:nw PM custodially as of 2026-08-20 00:47, explicitly NOT nw-surface ownership) - route to nw-lezama-cc or Elazar. RELATED: OPS-131 (cc alias shadows /usr/bin/cc) came out of this same thread. METHOD NOTE: three agents each generalised a single-host measurement to the fleet in this thread (bin-whey-cc `type -a`, bin-lezama-cc trailing `.`, bin-venus-cc exposure scope). Each was caught by another host measuring its own environment. A probe run in YOUR shell answers a question about YOUR shell.