Client-side command redaction only covers --secret, so --env credentials persist in plaintext in request records

Problem

While auditing what a debug dump exposes (see the dump-side redaction work), we found that the client-side construction-time redaction in common_utils._redact_secrets_values only rewrites --secret KEY=VALUE arguments. Credentials passed via --env KEY=VALUE are never redacted client-side, so they are persisted in plaintext in the requests DB — both in entrypoint_command-shaped strings and in the task YAML envs — for every new request. Dump-side redaction (the linked PR) scrubs them when a dump is created, but the stored rows themselves keep the plaintext values, and other persisted command strings (e.g. usage-lib messages) can still carry them.

Details

• sky/utils/common_utils.py:_redact_secrets_values handles --secret KEY=VALUE / --secret=KEY=VALUE only.
• --env MY_TOKEN=abc123 passes through verbatim and ends up in the persisted request body (which debug dumps are built from).
• The task YAML sent with sky launch --env ... similarly carries the value in its envs block.

Possible direction

Extend the client-side redaction to also rewrite --env KEY=VALUE pairs whose key matches a sensitive-name pattern (the dump-side debug_dump_helpers.is_sensitive_env_var deny-by-pattern logic — TOKEN/SECRET/KEY/PASSWORD/PASSWD/CREDENTIAL/URI plus an explicit list — could be reused), and consider whether the task YAML envs should be treated the same way at construction time.

Note: this only affects what is persisted for diagnostics; the request still needs the real values to execute, so any fix has to keep the functional path intact (similar to how managed-job relaunch snapshots must keep full env values).

-Claude