test(parity): run setup_cmd through the lane's CLI binary, not a hardcoded path

The runtime matrix runs in two lanes with different binaries: the push/PR lane
(task parity:runtime, deps build → ./devcontainer) and the daily coverage lane
(task coverage:parity-runtime), which builds only the instrumented binary under
artifacts/coverage/bin and points CLI_GO at it — it never builds ./devcontainer.

16 setup/cleanup commands hard-coded ${PARITY_REPO_ROOT}/devcontainer, so in the
coverage lane setup's `up` invoked a missing binary: no container was created and
the measured exec/run-user-commands reported "Dev container not found" (or, when a
trailing echo masked the exit 127, the same). The cases passed in the plain lane
and locally, so the divergence only ever surfaced in the daily — which was red on
the same ~13 exec/run-user-commands/compose-reuse cases every run.

parityEnv now exports PARITY_CLI_GO / PARITY_CLI_TS bound to the same binary the
measured command uses (mirroring the cliGO/cliTS defaults), and every setup/
cleanup/verify command routes through them. In the coverage lane setup now runs
the instrumented binary too, so it is both present and covered.

Verified by simulating the coverage lane locally (instrumented binary, CLI_GO set,
./devcontainer removed): the previously-failing cases pass.

Regression tests: TestParitySetupUsesLaneBinary asserts parityEnv exports the vars
and no matrix command re-hardcodes the path. TestWorkflowRuntimeJobsShareComposite-
Action and TestWorkflowDailyLanesGatedOnChanges retro-cover the sharding commit's
reuse and daily-change gating.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: aledbf