GeezerVison

Follow-up to #57.

run-user-commands --ca-bundle took a bundle path, checked that it held PEM, and then used it only as a switch: the variables it set point at the copy up bound into the container, never at the file passed. up --ca-bundle already puts those variables in the container's environment, and the lifecycle commands inherit them through the user-env probe, so the flag added nothing.

• run-user-commands no longer takes --ca-bundle (it is now an unknown flag); caBundleRemoteEnv and containerHasCABundle are gone with it.
• docs/go-only-features.md, docs/DIVERGENCES.md and docs/parity/cli-flags-inventory.yaml list the flag on build and up only.

Compatibility: the flag arrived in #57 and no release contains it (latest is v20260921.02), so no user depends on it.

Tests

• TestRunUserCommandsTakesNoCABundle: fails on main (the flag is accepted), passes here.
• TestE2E_CABundle: after up --ca-bundle, run-user-commands with no flag reruns a postAttachCommand that reaches the TLS server signed by the test CA.

Validation (local)

• go tool task lint: pass.
• go test ./internal/cli/ -run 'CABundle|RunUserCommands|Inventory' (e2e included, with Docker): pass.
• go tool task test:race and go tool task parity:contract: the only failures are the TestOpen* tests, TestComputeWorkspaceConfigOutsideARepository and two read-configuration parity cases. The first two groups fail identically on main; all trace back to a /tmp/.git on the dev machine. CI is the check for those.

🤖 Generated with Claude Code