e2e.sh: untracked-file collisions abort provisioning; failed restore brings up CANONICAL_DIR even when the live stack runs from a bundle dir

[VijitSingh97]

Two defects surfaced during the v1.4 release gate (2026-07-12):

1. Provisioning aborts on untracked files. /srv/code/pithead-e2e had an untracked tests/integration/benchmarks/bench-verify-egress.sh left by an earlier bench run; git checkout develop refused ("would be overwritten") and the run died in preflight. The e2e checkout is DEDICATED and disposable — provisioning should git checkout -f + git clean -fdx (excluding results//backups/ if worth keeping) instead of assuming a pristine tree.

2. Restore assumes CANONICAL_DIR runs the live stack. The restore path runs pithead apply/up from CANONICAL_DIR (default /srv/code/pithead, the source checkout on main). On gouda the LIVE stack runs from the per-version bundle dir (/srv/code/pithead-v1.3.1); the restore therefore had the source checkout take over the compose project with locally-built :dev images — tari crash-looped and the restore itself exited non-zero, leaving the box needing a hand-run pithead upgrade from the bundle dir. Workaround that works today: pass CANONICAL_DIR=/srv/code/pithead-vX.Y.Z. Fix: either derive the restore dir from the running container's com.docker.compose.project.working_dir label, or refuse to start when CANONICAL_DIR's compose project differs from the live one.

Neither blocked v1.4 (retried with the workaround) but both burn a release-gate cycle each time.

[VijitSingh97]

More harness defects from the v1.4 gate run (2026-07-12), all environmental — no develop code regression, but each flakes the matrix and needs hardening:

1. pool type asserts too early / doesn't tolerate Tor. detect_pool_type (collector/pools.py) classifies by peer TCP port (37889/37888/37890). On a freshly-cycled scenario (captured at 2–9 min uptime) the peer list is too sparse to classify → returns Unknown, and under Tor peers are onion addresses that may not present a port-identifiable suffix until the list fills. Steady-state prod classifies correctly (dashboard shows "P2Pool Main"), so this is capture-timing, not a product bug. Fix: retry the pool type assertion with a timeout (wait for .pool.type != Unknown, ~60–120s) instead of a single immediate read.

2. workers online (>= 1) needs a stable worker. With a single borrowed miner across rapidly-cycling scenarios, the worker doesn't reconnect+register before capture in several scenarios. Fix: borrow 2 miners (miner-1 + miner-2 are the pithead loaners), and/or wait-for-worker with a timeout before the assertion.

3. Stale results dir contaminates diagnosis. results/<scenario>/ from a prior run (a chore/deps-p2pool-4.16 build) survived into this run's dir, so artifacts read as another branch's state. Fix: rm -rf results/* (or a fresh temp dir) at harness start.

Separately, the #374 backup-default incompatibility (harness pithead backup -y now refuses without a passphrase) is fixed in #456 (--no-encrypt on the throwaway bench backups).

Net for the v1.4 gate: the only code-caused failure was the #374 backup one (fixed); the rest are these harness gaps. Re-running post-#456 to confirm.

[VijitSingh97]

Merged into develop-v1.5 (the v1.5 integration branch, live during the v1.4 freeze) via #467. GitHub doesn't auto-close on merges to a non-default branch, so closing manually. Ships in v1.5; folds into develop when develop-v1.5 collapses after the v1.4 cut.