fix(net): redact userinfo from PAC source in logs

[pmaxhogan]

The defect

A PAC source can be a URL carrying basic-auth credentials:

http://corpuser:hunter2@wpad.corp/proxy.pac

That string was written verbatim into:

• the PAC runtime warning (PAC evaluation failed at request time...),
• the refresh-failure warning added in fix(net): refresh stale PAC scripts instead of pinning them for the process #191,
• ProxyConfig's Debug (the Pac arm printed engine.source),
• and every ProxyError Display message carrying a url / location,
  which are logged and surfaced to the settings UI.

This one is live, not latent. Driven's rolling logs are collected into the
SPEC s18 diagnostic bundle, and the bundle's Redactor scrubs by prefix/shape -
OAuth tokens (ya29., 1//), drive-id shapes, emails, absolute paths. None of
those patterns match a proxy password, so it would ride straight through into a
bundle shared with support. Same defect class as #190, different escape route:
#190 leaked it through the settings document, this leaks it through the logs.

The fix

Redact at the point of writing, never after:

• PacEngine no longer retains the raw source. The field exists purely to
  be printed, and refetching keys off the caller's own source string, so the
  engine stores only the redacted form. That fixes the runtime warning and
  ProxyConfig's Debug at the root rather than at each print site.
• The refresh-failure warning redacts its source.
• Every ProxyError variant with a url / location redacts it in
  Display, via a thiserror format expression
  (#[error("...{}...", redact_userinfo(.url))]). The struct fields keep the
  raw value, so redaction is a property of the message, not of the data.

This covers the ProxyError::Display item from #204 - it fell out naturally,
since that is the same set of messages. The other #204 items
(custom_root_ca_path, pre/post_backup_hook, PAC-mode proxy_url as a local
path) are untouched and remain #204's scope.

One deliberate cross-crate change

The redactor now lives in driven-tls as redact_userinfo, and the copy added
to src-tauri in #190 delegates to it. It was written there first, but the same
scrub is now needed in the proxy layer itself, and two copies of a redaction rule
are two chances for one of them to drift. Behaviour is unchanged - #190's tests
pass untouched against the shared implementation. Easy to revert to two copies if
you would rather keep the crates independent.

Tests

Four new tests in crates/driven-tls/src/proxy.rs:

• redact_userinfo_handles_every_url_shape - no-credential passthrough, a bare
  filesystem path (the PAC-from-disk case), socks5, username-only, a password
  containing @, path/query not mistaken for the authority, an @ inside a
  path left alone, and unparseable-garbage-with-an-@ redacted wholesale.

• pac_engine_never_retains_the_raw_source - the engine's stored source and
  ProxyConfig's Debug are both clean, while the host survives for
  diagnostics.

• proxy_error_display_redacts_credentials - all six URL-bearing variants, plus
  an assertion that the underlying field is still unredacted (redaction is a
  property of the message).

• a_failing_pac_fetch_does_not_leak_credentials_in_its_message - drives a
  real transport failure (loopback port 1 refuses instantly) rather than a
  synthetic string, then pins both halves of the resulting message separately:

  PAC file could not be fetched from `http://<redacted>@127.0.0.1:1/p.pac`:
  error sending request for url (http://127.0.0.1:1/p.pac)
  

  The first half is our Display doing its job. The second half is reqwest's own
  text, which embeds the URL but strips the userinfo itself - we depend on that,
  so the test asserts it. A future reqwest that stopped stripping would
  reintroduce the leak through that nested field, and this test is where we would
  find out.

Negative control: with redact_userinfo neutered to return its input
unchanged, all four new tests fail (36 passed / 4 failed) and pass again once
restored - so none of them is vacuous.

Gates run locally: cargo test --workspace (1238 passed, 0 failed),
cargo clippy --workspace --all-targets -- -D warnings (clean),
cargo fmt --all -- --check (clean). No UI changes, so the pnpm gates do not
apply. No dependency changes, so cargo deny is unaffected.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Qu8GxMwkuxF7JBzwRjtcw7

[github-actions]

Coverage

Area	main	this PR	delta
Rust (lib crates)	81.21%	81.24%	+0.04 (OK)
UI (vue/ts)	91.39%	91.39%	+0.00 (OK)

Gate: passed - no coverage regression (epsilon 0.1 pp).