Browser navigation bypasses private-network and cloud-metadata guards

[NotASithLord]

Problem

Direct fetch and document-reading paths block localhost, private-network, and
cloud-metadata targets. Browser navigation does not apply the same guard.
navigate accepts ordinary HTTP and HTTPS URLs, and the origin sensitivity
classifier currently treats IP literals and localhost as ordinary origins.

A browser actor can therefore open a local service and then use page tools on
it. A public URL can also redirect a driven tab to a private target. This is a
different path from the audited open-web fetch relay and bypasses its SSRF
checks.

Why this matters

Local dashboards, development services, router pages, and cloud metadata
surfaces may trust the browser or local network. Untrusted page content should
not be able to steer an actor into those targets and read or operate them.

Acceptance

• Classify localhost, private IP space, link-local targets, and cloud metadata
  as sensitive for browser automation.
• Enforce the check before navigation and again against the committed origin so
  redirects cannot bypass it.
• Apply the same rule to scripting and debugger paths, bound and roaming web
  actors, and any raw tab-id entry point.
• Keep explicitly configured local model-provider traffic on its separate
  provider path.
• Return a clear user-facing refusal and a structured model-facing reason.
• Add tests for localhost names, IPv4, IPv6, IPv4-mapped IPv6, unusual numeric
  forms accepted by URL parsing, and public-to-private redirects.
• Update store and security claims only after the browser path is covered.