[BUG] Regression of #86362 — Browser pane still blocks same-origin subresources (ERR_BLOCKED_BY_CLIENT) for hostnames resolving to 127.0.0.1

#86362 was closed as completed with no linked fix or version. The bug still reproduces.

Environment

• Windows 11 Pro 10.0.26100
• Claude desktop app, UA: Claude/2.7032.0 Chrome/152.0.7977.130 (MSIX)
• Hostname mapped to 127.0.0.1 via the Windows hosts file, e.g. dev.example.test; IIS over HTTPS on 443

Repro (run in the pane's page context after navigating to https://dev.example.test)

await fetch('/')             // TypeError: Failed to fetch
await fetch('/favicon.ico')  // TypeError: Failed to fetch
await fetch('https://cdn.jsdelivr.net/npm/jquery@3.7.1/package.json')  // 200

Network log

GET https://dev.example.test/            → 404 (top-level navigation, allowed)
GET https://dev.example.test/            → FAILED: net::ERR_BLOCKED_BY_CLIENT (fetch, same URL)
GET https://dev.example.test/favicon.ico → FAILED: net::ERR_BLOCKED_BY_CLIENT

The same URL loads as a navigation and is blocked as a subresource seconds later. Public cross-origin requests from the same page succeed. See #86362 for the full analysis and other affected setups (DDEV, multi-tenant vhosts, mkcert).

Could a maintainer say which build was meant to fix #86362, or reopen it?