fix(provision): never block startup on a missing fduty CLI; stage it on binary-only installs

[ysyneu]

Problem

A runner refused to start when the fduty CLI was absent — most visibly on macOS, where flashduty-runner serve died immediately with fduty CLI not ready right after install.sh reported "Already at vX, nothing to do."

Two coupled defects:

1. The startup gate was fatal. ensureFdutyCLI() error aborted run/serve when fduty couldn't be provisioned/verified.
2. install.sh never staged fduty on binary-only / darwin installs. install_bundled_fduty sat after the early return on the darwin/--no-service path, so the fduty bundled inside the release archive was extracted but never placed. Re-running install.sh didn't help either: the "already up to date" short-circuit returned before staging.

Net on macOS: no fduty anywhere the runtime looks → the (then-fatal) gate bricked startup.

Fix

Gate is now non-fatal (cmd/provision.go, serve.go, main.go). ensureFdutyCLI() still best-effort auto-stages fduty and self-checks it on the bash PATH, but on failure it logs an actionable manual-install hint and the runner starts anyway. A runner can still do non-fduty work, and a missing CLI is far easier to fix on a running, loudly-logging runner than on one that won't boot. fduty calls 127 until the operator resolves it — surfaced, not silently fatal.

install.sh staging fixed. install_bundled_fduty → stage_bundled_fduty(dir), now called on both paths:

• service installs → $BIN_DIR (env-pinned runtime tools dir)
• binary-only / darwin → $INSTALL_DIR (on the user's PATH, and the dir darwin's bundledFdutyNextToExe() probes — os.Executable() there returns the /usr/local/bin symlink, not its target; verified empirically)

The "already up to date" short-circuit now also requires fduty_present (mode-aware) so a re-run self-heals a missing fduty instead of declaring success while the CLI is absent.

Verification

• Live: built the runner, ran run with fduty fully scrubbed from PATH + an empty bin dir → it logs the install hint and proceeds through workspace initialized → health server listening → connecting to Flashduty (only exits on the bogus WS URL, not on fduty). Before this change it aborted right after "starting".
• Unit: new TestEnsureFdutyCLI_NeverFatalWhenUnprovisionable (deterministic missing-fduty branch via scrubbed PATH); extracted-function tests for stage_bundled_fduty + fduty_present (stage-to-INSTALL_DIR, stage-to-BIN_DIR, present/absent, no-fduty-member no-op).
• go build ./..., go vet ./..., go test ./..., gofumpt -l, shellcheck -s sh install.sh — all green.

Notes

• The building blocks provisionFduty / verifyFdutyOnPath keep their error-returning contracts (still unit-tested); only the ensureFdutyCLI integration point swallows the error into a log.
• The systemd/service install path is unchanged in behavior.