[ENG-4057] Share one outbound guard between protections and release it on stop

[patchstackdave]

Outbound request screening now works the same way however many protections a process creates.

Shared guard. fetch and node:http/node:https are process-wide, so each protection created with egress: true now registers its own screen with one shared guard.

• A call is refused when any registered screen refuses it, and each protection reports its own refusals through its own onEgressBlock and detections. A host in one protection's allowHosts is still refused when another protection refuses it.
• On the node:http path, a hostname is resolved once, and that resolution is checked by every screen that resolves the host. The connection is then pinned to addresses all of those screens accepted. A screen whose allowHosts lists the host still skips that host's DNS check, as before.
• uninstallEgress() removes only that protection's screen. When the last screen leaves, the original functions are restored. As before, a wrapper that another library layered on top is never overwritten.

stop() and stopRefresh().

• protection.stop() now also removes the protection's outbound screen. A protection created after another has stopped screens with its own rules.
• protection.stopRefresh() stops only the rule refresh: the poll loop and its recovery retries. Outbound screening and the reporters keep running. It used to be an alias of stop(), so test cleanups that relied on the full shutdown now call stop().
• AGENT-INSTALL.md and the type declarations describe both.

Unusual fetch input. A fetch call whose arguments the runtime's Request rejects is still handed to the underlying fetch unchanged. Its destination is now screened when it can be read (a URL string, a URL, or an object with url or href). When it cannot be read, the call is counted as an unscreened egress:unrecognised-request skip.

Validation: full suite (3,445 passed, 7 skipped), typecheck, build, and capabilities:check.

Field test outstanding. This changes AGENT-INSTALL.md, so the hostile field test must run immediately after the release that contains it. A run before that release would inspect the previously published docs, so it can't gate this change. Until then, the disclosure tests and capabilities:check are what cover the wording.

Refs ENG-4057

🤖 Generated with Claude Code

[coderbuds]

Cohesive implementation of a shared egress guard with thorough lifecycle handling.

🎯 Quality: 87% Excellent · 📦 Size: Large — consider splitting if possible

🛡️ Standards: Not checked — 404 lines changed, over your team's 400-line limit, and nothing checked before it was opened. Coding agents can call the assess-change-fit tool first, while a change this size is still cheap to split.

🤖 Authorship: Agent-written — Claude Code, going by its own attribution. Whether a person read it is unknown; coding agents can call the report-ai-usage tool to say.

📈 This month: Your 161st PR — above team average · Averaging Good

_{See how your team is trending →}

[patchstackdave]

/review