net: replace hand-rolled transport with HttpClient

AGENTS.md

@@ -277,14 +277,14 @@ libpng/libjpeg/libwebp on Linux. It is also the only engine project with
 `AllowUnsafeBlocks=true`. Every other engine module under
 `src/Starling.{Common,Url,Net,Html,Dom,Css,Layout,Paint,Js,Bindings,Mcp,Telemetry,Engine}/`
 stays **pure managed** — no P/Invoke, no native dependencies beyond what the
-.NET BCL ships. **TLS path: BouncyCastle.** `Starling.Net` uses
-`BouncyCastle.Cryptography` (pure-managed, no P/Invoke) for TLS 1.3 via
-`BcTlsTransport`. The `wp:M3-06e` SslStream migration was rolled back in
-`939f3a5 fix ssl crash` (2026-05-14) after a macOS TLS 1.3 issue surfaced in
-integration; re-attempting SslStream — or formally re-blessing BouncyCastle as
-the long-term path — is a tracked open item in `wp:M3-06-native-interop-pivot`'s
-handoff log. The interop-seam policy is still satisfied either way, because
-BouncyCastle adds no native dependency. CI greps the engine-project allowlist
+.NET BCL ships. **One carve-out: `Starling.Net`.** As of 2026-07-07 it runs on
+`System.Net.Http.HttpClient` over `SocketsHttpHandler` (transport, TLS, HTTP/1.1,
+HTTP/2), which reaches native crypto through the BCL. The BouncyCastle TLS client
+was deleted. `Starling.Net` still writes no P/Invoke of its own, so it stays off
+the interop grep, but it is no longer strictly pure-managed at runtime — the
+"managed-first" rule now means "no P/Invoke in our code," not "no native code
+anywhere below us." Cert trust stays ours: `HttpClient` chains to the bundled
+CCADB root store via a custom `ConnectCallback`, not the OS store. CI greps the engine-project allowlist
 (every engine project *except* the Codecs interop project); the lint job fails
 if you regress it. The GUI shell (`src/Starling.Gui`, Avalonia 12) and the Aspire
 AppHost/ServiceDefaults projects are exempt — they link against Avalonia desktop

browser-plan/00_INDEX.md

@@ -27,7 +27,7 @@
 | UI | Avalonia 12 (stable 12.0.x, released Apr 2026; targets .NET 10 directly; .NET 8+ only) | user |
 | Rasterization | `SixLabors.ImageSharp` 3.x + `SixLabors.ImageSharp.Drawing` 2.x + `SixLabors.Fonts` 2.x | user |
 | JS engine | The Starling JS engine, written from scratch in C#. No third-party JS engine dependencies. | user |
-| Networking | Hand-written from `System.Net.Sockets` up. No `HttpClient`, no `SslStream`. | user |
+| Networking | `System.Net.Http.HttpClient` over a configured `SocketsHttpHandler`, wrapped by the `StarlingHttpClient` facade. Browser policy (redirects, cookies, cert trust) stays in Starling; the transport (HTTP/1.1, HTTP/2, TLS) is the BCL's. Reversed the earlier hand-rolled-from-`Sockets` decision on 2026-07-07; see `03_NETWORKING.md`. | user |
 | Process model | Single-process for v1. Ladybird-style multi-process sandboxing deferred to v2. | this plan |
 | Cross-platform | Windows + macOS + Linux from day one. No platform branches without an `OPEN QUESTION`. | user |
 | Threading | Single-threaded UI + event loop. Worker pools for parsing/networking/JS. Details in `01_ARCHITECTURE.md`. | this plan |

browser-plan/03_NETWORKING.md

@@ -1,5 +1,21 @@
 # 03 — Networking
 
+> **Status (2026-07-07): switched to `HttpClient`.** The hand-rolled transport —
+> UDP DNS, the raw `Socket` dialer, the BouncyCastle TLS client, the HTTP/1.1
+> parser, the HTTP/2 + HPACK stack, the connection pool, and the body decoders —
+> was deleted. `StarlingHttpClient` is now a thin browser-policy wrapper over
+> `System.Net.Http.HttpClient` on a configured `SocketsHttpHandler`. This
+> reverses the "no `HttpClient`, no `SslStream`" rule that the rest of this doc
+> was written under. What Starling still owns: redirects (the engine follows
+> them; `AllowAutoRedirect` is off), cookies (our `CookieJar`, not
+> `CookieContainer`; `UseCookies` is off), and cert trust (the bundled CCADB
+> root store via a `ConnectCallback` that also captures the leaf for the lock
+> UI). What the BCL now owns: TCP, TLS, HTTP/1.1, HTTP/2, decompression, and
+> pooling — plus native crypto under the hood, which is why the engine is no
+> longer strictly pure-managed (see `AGENTS.md` interop policy). The sections
+> below describe the retired design and are kept for history; trust this banner
+> where they disagree.
+
 ## Scope
 
 **In:** URL parsing, DNS, TCP, TLS 1.3 (via `SslStream`), HTTP/1.1, HTTP/2 + HPACK, cookies, content decoding (gzip/brotli/deflate), HTTP cache, fetch primitives. Public seam for the engine.
@@ -42,11 +58,13 @@ its clean bill on the CI grep.
 > `wp:M3-06-native-interop-pivot`'s handoff log. See `AGENTS.md` §"Interop
 > policy" for the current authoritative statement.
 
-**No `HttpClient`.** We do not use `System.Net.Http.HttpClient` — the HTTP/1.1
-stack (and the planned HTTP/2 stack) is hand-rolled. That is the whole point of
-this doc: the engine owns connection pooling, cookies, caching, redirects, and
-cert trust, none of which `HttpClient` lets us control to browser spec. The ban
-on `HttpClient` is unchanged.
+**`HttpClient` (as of 2026-07-07).** Superseded by the status banner at the top.
+We now use `System.Net.Http.HttpClient` over `SocketsHttpHandler`. The pieces a
+browser must control — redirects, cookies, and cert trust — are kept above the
+transport by turning off the handler's automatic redirect and cookie handling
+and by validating certificates against the bundled root store in a custom
+`ConnectCallback`. Everything else (pooling, HTTP/1.1, HTTP/2, decompression) is
+the handler's job.
 
 What we *do* use:
 - `System.Net.Sockets.Socket` (raw TCP / UDP, fully managed).
@@ -470,5 +488,5 @@ Used by [10_WEB_APIS.md#fetch](10_WEB_APIS.md#fetch).
 - [ ] Gzip and Brotli-encoded bodies decode byte-identical to non-encoded servers.
 - [ ] Connection pool reuses a TCP connection across two sequential HTTPS requests to the same origin.
 - [ ] All of the above pass on Windows, macOS, Linux in CI.
-- [ ] `grep -rn 'System.Net.Http\|HttpClient' src/Starling.Net/` is empty (the `HttpClient` ban stands; `SslStream` is now the sanctioned TLS path).
-- [ ] `grep -rn 'DllImport\|LibraryImport' src/Starling.Net/` is empty — `Starling.Net` is not a designated interop project.
+- [ ] `Starling.Net` builds against `System.Net.Http.HttpClient` — the earlier `HttpClient` ban is lifted (see the status banner). TLS is the BCL's (`SslStream` under `SocketsHttpHandler`), not BouncyCastle.
+- [ ] `grep -rn 'DllImport\|LibraryImport' src/Starling.Net/` is still empty — `Starling.Net` writes no P/Invoke itself, even though the `HttpClient` it now calls uses native crypto internally.