Telemetry scrubber: case-insensitive mysql rule redacts an attached port (-P3306) and lets a real password survive in the same command #815

Summary

In server/src/telemetry/scrub.ts, the tool-anchored mysql credential rule keeps the i flag:

[
  /(\bmysql(?:dump)?\b(?:[^|;&\\\r\n]|\\[\s\S])*?(?:[ \t]|\\\r?\n)-p)("[^"]*"|'[^']*'|[^\s'"-]\S*)/gi,
  (_m, lead) => `${lead}${REDACTED}`,
],

i makes (?:[ \t])-p match the uppercase attached port form -P3306 (mysql's syntax for --port attached to a single dash). Because the g continuation after the first match never sees another \bmysql\b anchor, a real password later in the same command line is not redacted.

Repro (upstream tree at e8bb2736)

scrubCommand("mysql -h db -P3306 -phunter2 app")
→ "mysql -h db -P[REDACTED] -phunter2 app"

The port is redacted as if it were a secret, and the actual password -phunter2 survives into OTLP export — contrary to the module header's stated priority ("a secret that survived costs a rotation") and to the sibling sshpass rule, which is deliberately case-sensitive with the comment "Case matters here: -P is sshpass's prompt".

Suggested fix

Drop i from the mysql rule (/gi → /g), matching the sshpass rule's convention:

• mysql -h db -P3306 -phunter2 app → mysql -h db -P3306 -p[REDACTED] app
• lowercase -p3306 (attached password form) is still redacted
• mysqldump -phunter2 db unchanged

Tests worth pinning: the mixed -P/-p command above, the lowercase attached form, and mysql -p database (space form = interactive prompt, database name must not be redacted).

Context: we hit this in a downstream deployment while extending coverage for SSHPASS=… sshpass -e and docker <global-options> login -p …; the case-sensitivity divergence was found by a full-scope review pass. Happy to send a PR if wanted.