Resolve binaries in parent shell before tmux send-keys

[samsondav]

Fixes #458.

Problem

If tmux is launched from one nix env and start-canton.sh or start-frontends.sh is later re-run from another nix env, the panes pick up the binary from the tmux server's inherited PATH (the first env) rather than the active env. The failure is silent and produces confusing debugging sessions, as flagged by @moritzkiefer-da on DACH-NY/canton-network-node#19787.

Fix

Resolve canton, toxiproxy-server, and npm via command -v in the parent shell and substitute the absolute path into the tmux command string. The pane invokes the binary directly regardless of the tmux server's PATH.

If the binary is missing on PATH, fail fast in the parent shell with a clear message before any tmux session is created, instead of failing silently inside a pane.

This matches the first idea from the issue body (resolve via which, execute the result). The second idea (nix develop path:nix in every pane) is not used here because the issue notes a prior attempt made CI startup measurably slower.

Scope

• start-canton.sh: $CANTON (default canton, overridable via -c) and toxiproxy-server.
• start-frontends.sh: npm (used by start_frontend, start_test, and wait_for_workspace_build panes).

Out of scope: tee and other coreutils — these were not the reported failure mode and are typically identical across nix envs. sbt and jq/jsonnet are invoked from the parent shell, not from a tmux pane, so they already pick up the active env's PATH.

Behavior

• Default invocation (single nix env): no behavior change. command -v canton returns the same absolute path the pane would have resolved through PATH.
• Mixed nix envs (the bug): pane runs the binary the user's current shell sees, not the tmux server's first-env binary.
• Missing binary: script exits with start-canton.sh: 'canton' not found on PATH (or similar) before any tmux session is created.
• -c <custom-canton> with an absolute path: passes through unchanged via command -v.