fix: make fduty resolvable by bare name in BYOC sandboxes (single writable tools dir + hard-fail self-check + bundling)

[ysyneu]

Problem (root cause)

fduty is unreachable by bare name inside BYOC self-hosted runner sandboxes — bash: fduty: command not found (exit 127). The runner held two divergent notions of "where fduty lives":

• PATH dir = BundledToolsDir() = filepath.Dir(os.Executable()) = /usr/local/bin, which is read-only under the systemd unit's ProtectSystem=strict (no sudo, NoNewPrivileges).
• Install dir = the same value passed as FLASHDUTY_INSTALL_DIR, but flashduty-cli's install.sh relocates to $HOME/.local/bin when the target is unwritable — a dir never added to the bash tool's PATH. → 127.

End-state: one runner-owned, writable, deterministic tools dir

Collapse "install dir" and "PATH dir" into a single directory so they cannot diverge by construction. No PATH enumeration (explicitly out of scope — brittle across environments).

1. BundledToolsDir() now defaults to <runner home>/bin — home resolved the same way cmd resolves it (FLASHDUTY_RUNNER_HOME > deprecated FLASHDUTY_RUNNER_WORKSPACE alias > ~/.flashduty). Under the systemd unit that root is inside ReadWritePaths=${STATE_DIR}, so it's writable even with ProtectSystem=strict — install.sh never takes its ~/.local/bin fallback branch. The same value feeds both the PATH prepend and FLASHDUTY_INSTALL_DIR. FLASHDUTY_RUNNER_BIN_DIR still overrides outright, so the AGS cloud image (baked /usr/local/bin/fduty, FLASHDUTY_RUNNER_BIN_DIR=/usr/local/bin) is unaffected.
   • cmd pins FLASHDUTY_RUNNER_HOME from the resolved config before provisioning so the --workspace flag path can't desync the tools dir from the workspace.
2. install.sh creates + chowns ${WORKSPACE_DIR}/bin (== the runtime tools dir; under the existing recursive chown / ReadWritePaths). No unit change.
3. Startup functional self-check, HARD-FAIL. ensureFdutyCLI now returns an error and aborts startup. After staging, it runs fduty version through the exact bash-tool env (new environment.BashToolEnv() — secrets scrubbed, bundled dir first on PATH) via bash -c and asserts exit 0. A runner that boots "healthy" but 127s every fduty call is worse than one that refuses to start.
   • Subtle root-cause detail: it must go through bash -c, not exec.Command("fduty", ...). Go's LookPath resolves the program against the parent process PATH and ignores cmd.Env, so a direct exec would miss the bundled dir and not mirror real call-time resolution.
   • The legitimate "already provisioned" soft path is preserved (binary already present → no install), but the self-check still runs and still gates startup.

Bundling (2nd commit) — remove boot-time network fragility

Ship the matched-os/arch fduty inside each runner release archive:

• scripts/bundle-fduty.sh (goreleaser before hook) downloads the pinned flashduty-cli release (v1.3.4) for every os/arch, extracts the binary → .fduty-bundle/<goos>_<goarch>/fduty(.exe).
• .goreleaser.yaml includes it per archive via a templated archives.files glob.
• install.sh stages the extracted fduty into the writable tools dir at install time.
• CDN install path kept as a fallback when the bundled binary is absent (old archives / skipped os/arch) — purely additive.

Verification

• go build ./..., go test ./... — all green (new tests: BundledToolsDir default/alias/override resolution; copyExecutable; provisionFduty no-op + no-source-error; verifyFdutyOnPath pass/fail via a stub fduty on PATH).
• golangci-lint run ./... — 0 issues. shellcheck install.sh scripts/bundle-fduty.sh — clean.
• goreleaser check — config valid. goreleaser release --snapshot — hook fetched real v1.3.4 binaries; every tar.gz/zip contains fduty(.exe); bundled darwin/arm64 binary runs (flashduty version 1.3.4).
• End-to-end on host: extract archive → install.sh stage into <workspace>/bin → bash -c 'fduty version' with prepended PATH → exit 0 (the production self-check path).