Stale cli.py / _bin/ references survive #7 cleanup, break tests and action_surface gate

[zackees]

Stale references survive the raw-wheel-script refactor

Same failure shape as fbuild#748: a packaging refactor (#7 — drop the Python CLI shim, ship template-cli as a raw wheel script) worked at the wheel-build / runtime level but left stale references in tools that walk the source tree a different way. Three of them visible in git grep cli.py _bin:

Broken

1. tests/test_cli.py does from template_python_rust_cmd.cli import packaged_binary_path — module deleted in fix(install): ship template-cli as raw wheel script; drop Python shim #7. pytest collection fails with ImportError. The whole test file is now unrunnable.

2. ci/gates/action_surface.py:49 has ROOT / "src" / "template_python_rust_cmd" / "_bin" / BINARY_NAME as its first candidate in _binary_path(). That directory was removed in fix(install): ship template-cli as raw wheel script; drop Python shim #7 (the binary now lands in the wheel's .data/scripts/ directly, not staged into the package source tree first). The fallback candidates (target/release/, target/debug/) still work for the dev ./test flow, but they don't honor CARGO_TARGET_DIR — pinned by perf(install): pin CARGO_TARGET_DIR + disable PEP 517 isolation #5 to ~/.template-python-rust-cmd/cargo-target/wheel-build/. After BUILD_PROFILE=dev (feat(build): BUILD_PROFILE=dev env var for fast local iteration #8) lands in a release-path build context, that pinned dir is where the binary actually is, and action_surface skips the runtime check with a "no binary found" warning.

3. tests/README.md:10-11 still describes test_cli.py as covering "the Python CLI shim's binary-discovery logic" — module gone, doc stale.

Why this is analogous to fbuild#748

PR #748 fixed a case where package-dir worked correctly for the wheel build but produced a PEP 660 meta-path finder whose MAPPING was too narrow — runtime imports worked, but static analyzers walking top_level.txt / .pth files couldn't resolve from fbuild.api import …. The bug only showed up in tools that walked the artifact differently from how the wheel-builder did.

Here the wheel-build path is fine: ci/build_wheel.py produces a working wheel with template-cli.exe at <name>-<ver>.data/scripts/. But artifact-walking tools — pytest discovering test modules, action_surface probing the source tree for the staged binary — still expect the pre-#7 layout. Same failure shape, different tool surfaces.

Fix

• tests/test_cli.py — replace the template_python_rust_cmd.cli import with a test against the actual installed template-cli binary on PATH (via shutil.which). Asserts the binary exists and is invokable. The original test's intent — "the package can locate its CLI" — is preserved; the implementation matches the new shipping mechanism.
• ci/gates/action_surface.py::_binary_path() — drop the dead _bin/ candidate. Add a CARGO_TARGET_DIR honor (mirror the resolution in ci/build_wheel.py::_cargo_target_root) so the gate finds the binary even when the wheel-build path put it under the pinned target dir. Keep target/release/ and target/debug/ as fallbacks for the dev ./test flow. Update the user-facing warning to match the new search paths.
• tests/README.md — describe what test_cli.py actually tests now (binary-on-PATH probe, not the deleted shim).

Acceptance

• uv run pytest tests/test_cli.py -v collects + passes (no ImportError).
• ./ci.sh action_surface finds the binary under CARGO_TARGET_DIR/release/ (the pinned wheel-build dir) when one exists, without needing to fall back to the "no binary found" skip path.
• grep -rn "_bin\|template_python_rust_cmd\.cli" tests/ ci/ src/ returns no live-code hits (READMEs may still reference them historically).