Strip control characters from the Command column (fixes #950)

[MsfPablo]

Fixes #950.

Problem

Command::add only replaced \n and \t before display. A process's command line — including argv[0] — is fully controlled by whoever started it, and /proc/<pid>/cmdline is world-readable, so any local user can plant a process whose command line contains a raw ESC/CSI/OSC sequence. When another user runs procs, that sequence reaches their terminal unmodified.

Fix

Adds util::sanitize_control_chars, which replaces every control character (C0 including ESC 0x1B and BEL 0x07, DEL, and C1) with a space, and applies it to the final Command value on all four platform impls (Linux/Android, macOS, Windows, FreeBSD). This supersedes the old newline/tab replacement, which is now a subset of the same rule.

Replacing rather than deleting keeps the surrounding text visible and the column width honest; the payload's remaining printable bytes (e.g. ]52;c;...) show up as inert text.

Scope is deliberately limited to the Command column, as reported.

Test

util::tests::test_sanitize_control_chars uses the reporter's scenario — an OSC 52 clipboard-write sequence wrapping a base64 marker, plus embedded tab/newline — and asserts the output contains no control characters, that CSI sequences are neutralized, and that ordinary command lines pass through unchanged.

Verification

Run on macOS.

$ cargo test
test result: ok. 13 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

$ cargo fmt --check
(clean, no output)

$ cargo clippy --all-targets -- -D warnings
12 pre-existing errors, byte-identical to the `git stash` baseline on the
same commit (unsafe_op_in_unsafe_fn in the macOS paths, collapsible_if,
unnecessary_cast, etc.). No new lints introduced by this change.

Disclosure

This patch was written with AI assistance (Claude). I reviewed the diff and ran the verification commands above myself.