[run] script payload embedding sudo fails with raw remote stderr and no local hint toward --sudo #97

Summary

sshx run --script-file now supports privilege escalation via --sudo (whole interpreter runs as root), and run --help warns "Do not embed sudo commands in a script". But when a payload does embed sudo and the caller forgot --sudo, the failure is raw remote stderr with no local diagnostic — unlike command mode, which has had a polished hint since #81:

$ sshx run --target=prod-web --json -- "true && sudo id -un" 2>&1 >/dev/null
⚠️  sudo is not the first token, so sshx cannot auto-fill a stored sudo password …
sshx: [prod-web] sudo is not the first token … Run the privileged part as `sudo sh -c "<full command>"` …

vs script mode — silence on the local side:

$ cat /tmp/s3.sh
#!/bin/sh
sudo -n true
$ sshx run --target=prod-web --json --script-file=/tmp/s3.sh 2>/dev/null | jq '{exit_code, stderr}'
{ "exit_code": 1, "stderr": "sudo: a password is required\n" }
$ sshx run --target=prod-web --json --script-file=/tmp/s3.sh 2>&1 >/dev/null | wc -l
0        # no local hint at all
$ sshx run --target=prod-web --json --script-file=/tmp/s3.sh --sudo 2>/dev/null | jq .exit_code
0        # works

An agent that only reads exit_code sees a generic remote failure; the fix (--sudo) exists but is only discoverable by re-reading help text.

Proposed

Mirror the #81 command-mode behavior for payloads: when ActionScript is selected, --sudo is not set, and the payload contains a sudo token (same tokenizer as CommandUsesSudo), emit a local stderr note once:

sshx: the script contains `sudo` but --sudo was not requested; sshx cannot inject a
password for a nested sudo (its stdin carries the script). Re-run with --sudo to run
the interpreter privileged, or remove the sudo calls.

Optionally also surface it in the JSON document as a notices[] entry (consistent with the notice policy from #86/#89).

Environment

• Built from origin/main 1be5f1d (v0.19.0-1); behavior identical on installed v0.17.0.
• Related: [sudo] run --target= resolves sudo key to 'master' instead of the host's sudo_password_key; only the first sudo in a chain gets the injected password #78, fix: policy-block visibility, sshx text read pipelining, and the non-leading sudo boundary #81, [run] Document --sudo for script payloads in per-verb help #92 (documentation-only fix), log entry 2026-09-20 in RAM-TA3 Tools/sshx-experience-log.md.