Wire MITM hooks into runtime enforcement

[evawong-oai]

Stack

1. Parent PR: Add MITM hook config model #18868 adds MITM hook config and model only.
2. This PR wires runtime enforcement.
3. User facing config follow up: Use named MITM permissions config #18240 moves MITM policy into the PermissionProfile network tree.

Why

1. After the hook model exists, the proxy needs a separate behavior change that can be tested at the request path.
2. This PR makes hooked HTTPS hosts require MITM, evaluates inner requests after CONNECT, mutates headers for matching hooks, and blocks hooked hosts when no hook matches.
3. It also fixes the activation path so a permission profile with MITM hook policy starts the managed proxy.
4. Keeping this separate from Add MITM hook config model #18868 lets reviewers focus on runtime effects, telemetry, and request mutation.

Summary

1. Store compiled MITM hooks in network proxy state.
2. Require MITM for hooked hosts even when network mode is full.
3. Evaluate inner HTTPS requests against host specific hooks.
4. Apply hook actions by replacing request headers before forwarding.
5. Block hooked hosts when no hook matches and record block telemetry.
6. Treat profile MITM hook policy as managed proxy policy so the proxy starts when needed.
7. Keep the duplicate authorization header replacement and query preserving request rebuild in this runtime PR.
8. Add runtime tests and README guidance for hook enforcement.

Validation

1. Ran the network proxy MITM policy tests.
2. Ran the hooked host CONNECT test.
3. Ran the authorization header replacement test.
4. Ran the core permission profile proxy activation test for MITM hooks.
5. Ran the scoped Clippy fixer for the network proxy crate.
6. Ran the scoped Clippy fixer for the core crate.

[winston-openai]

LGTM for the HTTP CONNECT path. One follow up I think we need to think through: SOCKS5 is also enabled by default and currently still opens a raw tunnel in full mode but the hooks don't apply. We either need to apply equivalent hook enforcement to SOCKS5 TCP HTTPS flows or fail closed for hooked hosts on SOCKS5 so folks can't bypass the hook policy. There's also the open question about what to do about the SOCKS5 UDP setup; my thought is we detect if it's HTTP3/QUIC and if so, mitm it, apply hooks and forward the requests, and otherwise proxy it (or fail closed - maybe there's another config option).

We can discuss this though - these things should be separate follow up PRs. I just want to call them out so that hooks are being applied properly

[evawong-oai]

Thanks. I agree.

I left SOCKS5 as follow up work. This PR only covers the HTTP CONNECT path. The next task should decide whether SOCKS5 uses the same hook path or blocks hooked hosts until that path is ready.

It should also cover UDP and QUIC before rollout.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2c9ccbe030

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".