CI: integration container tests the released dotf, not the PR's built binary

[mlorentedev]

Problem

tests/Dockerfile.integration copies the repo and runs setup-linux.sh, which installs dotf via scripts/install-dotf.sh — and that downloads the pinned release artifact rather than building from the PR's ./cli source. On top of that, dotf is not on the bats-time PATH (the verify-setup.bats ENTRYPOINT does not source the login profile).

Consequences:

• A new dotf subcommand cannot be integration-tested until it ships in a release. Surfaced by BUG-029/BUG: no journey creates machine.json — phantom DOTFILES_REPO_DIR default breaks update/mem/doctor --fix #696: the dotf env set seed and its two verify-setup.bats guards had to be made skip-until-released, because the container's released dotf predates env set.
• dotf env generate during setup is likewise only exercised against the released binary, and the bats-time command -v dotf skips (see the existing env path guard).

Proposed fix

• Build dotf from ./cli inside the integration image (or inject the CI-built binary) and put it on PATH before setup-linux.sh runs, so install-dotf.sh sees the current build and setup exercises the PR's code.
• Ensure dotf is on the bats-time PATH so the verify-setup.bats guards actually run (drop the command -v dotf ... || skip fallbacks once guaranteed).

Evidence

BUG-029 (#696) PR #732: the two [#696] machine.json guards skip in the container; the seed logic is covered by Go unit tests + the dotf doctor repo-dir check instead. Related: CLI-031 golden characterization tests (#672).