ccs bare-name fix: end-to-end fresh-spawn proof still unrun on lezama

2026-08-19/20: agent spawns on lezama died with a bare tmux [exited]. Root cause (bin-whey-cc, after retracting a 0-byte-stub theory; confirmed by bin-lezama-cc): TWO bare-name resolutions in a PATH-less non-interactive login shell - ccs-tmux.sh:74 CCS_CMD="ccs ..." and ccs.sh:383 exec claude. lezama has ~/.bash_profile, so bash login SKIPS ~/.profile:25-26 where the ~/.local/bin PATH line lives; ~/.bashrc returns early for non-interactive. whey+venus pass ONLY because they have no ~/.bash_profile - accident, not design. FIXED by pm-llmmsgsrv-cc, 2e6753c: ccs.sh v5.33 exports PATH="$SCRIPT_DIR:$PATH" after SCRIPT_DIR is set; ccs-tmux.sh v1.9 absolutizes CCS_CMD. Both hunks REQUIRED - tmux resolves ccs-tmux.sh:74 before ccs.sh runs, so the export cannot cover it. v5.34 (138df6b) is a cosmetic header fix only. WHY THIS ITEM EXISTS: the fix is VERIFIED-STATIC ON 3 HOSTS, VERIFIED-LIVE ON 0. lezama verification was ordering assertion (:167 export < :398 exec) plus an env -i simulation showing NOTFOUND before the export and resolved after. No agent has actually been spawned since the fix. whey and venus CANNOT supply the proof - neither ever reproduced the bug, so a passing spawn there exercises a path that was never broken. CLOSE CONDITION: one NEW session spawned on lezama via the real chain (sshlezama -> agent-attach.sh -> ccs-tmux.sh -> ccs.sh -> exec claude). NOT an attach - attaching runs on an already-open inode and proves nothing. pm-llmmsgsrv-cc ruled this non-blocking; it rides on the next real launch. Related: OPS-131 (cc alias shadows /usr/bin/cc). Side note recorded there: before 2e6753c, tmux-spawned sessions on lezama had NO ~/.local/bin on PATH, so cc resolved to the real compiler; as of v5.33 it resolves to ccs.sh - that exposure is NEW on lezama, long-standing on whey/venus.