SSH transfer optimizations: source-side compression and stale staging purge (v3.10.0)

[Asimatasert]

Summary

Two features for SSH dump jobs on slow links, plus a fix they surfaced:

• --compress-where source|target (default target, old behavior): with zstd/xz/bzip2, compress the dump on the source host before the transfer, so slow uplinks move the compressed artifact instead of the raw dump (20x+ smaller in practice). Falls back to target-side compression with a warning when the tool is missing on the source or compression fails — never blocks the backup. gzip is unaffected (pg_dump -Z already compresses in-format at the source).
• --from-stale <time> (default 72h, 0 disables): with --from-keep 0, purge this job's leftover dumps older than <time> from the source staging dir before dumping. Failed or interrupted runs never reach the post-transfer cleanup, so their dumps piled up in the source /tmp forever.
• Fix: the batch runner's YAML→args key list was missing the new options; also widened the --from-keep retention and fetch globs from _*.dump to _*.dump* so compressed staging artifacts are matched.

Both options are validated (enum / strict time format — config and YAML values pass through the same validation), supported in config files and jobs YAML, and documented in --help and all four READMEs.

Testing

Verified end-to-end against a postgres:16 + sshd container:

• source-side compression: compressed on source, transferred as .dump.zst, pg_restore -l integrity check on the decompressed artifact, source staging cleaned
• missing-tool fallback: warning + raw transfer + target-side compression
• stale purge scoping: only this job's old files removed; fresh files and other jobs' files kept
• --from-keep 1 retention with compressed staging names
• default path (no --compress-where) byte-for-byte old behavior
• YAML mapping: invalid compress_where/from_stale values in a jobs YAML are rejected by the child validation (proves the keys flow end-to-end)
• ./build.sh --check green, bash -n clean