test: add coverage for audit build-URL host-validation guard

[github-actions]

Test Gap Fixes

Test suite snapshot: 3361 unit tests, 7 integration tests in audit_it.rs (2 new), 3325+ tests overall across the suite (unchanged pass count elsewhere).

Added Coverage

Module	Function/Path	Why It Matters	Test Added
src/audit/cli.rs	validate_audit_url_host via ado-aw audit <full-build-url> (untrusted host, no --org)	Security-critical PAT-exfiltration guard — previously only unit-tested by calling the function directly; every subprocess test used a bare numeric build ID, so the CLI wiring path (parse_build_ref → resolve_audit_context → validate_audit_url_host) had zero end-to-end coverage	audit_rejects_untrusted_host_in_build_url_without_org_override
src/audit/cli.rs	validate_audit_url_host on-prem host mismatch against a trusted --org	Confirms an attacker cannot substitute the build-URL host while riding on an unrelated trusted --org anchor	audit_rejects_build_url_host_mismatched_with_trusted_org

Both tests invoke the real ado-aw binary as a subprocess (matching the existing pattern in tests/audit_it.rs) and assert the process exits non-zero with the guard's stderr message, exactly reproducing what an attacker-crafted ado-aw audit <malicious-url> invocation would trigger.

I also audited src/audit/analyzers/{ado_proxy,custom_jobs,missing,otel}.rs and src/compile/codemods/*.rs (this cycle's assigned modules per cache-memory) and found they already have solid in-module unit coverage (6-15 tests per file) — no meaningful gap there, so I redirected to this higher-value CLI-boundary gap instead.

Validation

• cargo test (3361 + 7 + other suites, 0 failures)
• cargo clippy --all-targets --all-features (0 warnings)

---

This PR was created by the automated test gap finder. Previous run: 2026-09-14. Modules audited this cycle: audit/analyzers/ado_proxy.rs, audit/analyzers/custom_jobs.rs, audit/analyzers/missing.rs, audit/analyzers/otel.rs, compile/codemods/, audit/url.rs, audit/cli.rs.*

Warning

Firewall blocked 3 domains

The following domains were blocked by the firewall during workflow execution:

• onprem.example.com
• spsprodeus21.vssps.visualstudio.com
• spsprodsbr1.vssps.visualstudio.com

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "onprem.example.com"
    - "spsprodeus21.vssps.visualstudio.com"
    - "spsprodsbr1.vssps.visualstudio.com"

See Network Configuration for more information.

Generated by Test Gap Finder · auto · 177.6 AIC · ⌖ 23.1 AIC · ⊞ 9.8K · ◷

[azure-pipelines]

Azure Pipelines:
2 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[jamesadevine]

Integrated into #2238 and validated there. Closing this source PR as superseded by the aggregate.