Make iframe previews local-first with an external-origin warning and allowlist

Iframe previews are primarily for local development tools: dev servers, Storybook, and similar applications. External documentation is a useful convenience, but this renderer should not try to provide a full authenticated browser experience.

Follow-up to #571. Ship that PR as-is; this enhancement is separate. Keep its ambient Cookie/Set-Cookie stripping, with no cookie jar in this first iteration.

## Proposed behavior

- Allow local loopback targets normally. Define local by the actual loopback destination; arbitrary private-network addresses or hostname string matches do not qualify automatically.
- Before opening a non-allowlisted external origin in the iframe renderer, show a prominent warning identifying the destination, with **Open in browser**, **Allow this origin**, and **Cancel** actions.
- Scope allowlist entries to an exact origin (scheme, hostname, and port). Make entries removable; decide persistence scope during implementation.
- Apply the policy to the initial URL and subsequent cross-origin navigation, including redirects, forms, and script-driven navigation. A click handler or a notification after navigation is not a sufficient gate. Establish what can be enforced in both VS Code and Tauri before choosing the mechanism.
- Approval permits a preview; it does not enable cookie authentication or expand supported URL schemes. The current proxy supports HTTP upstreams only. Unsupported targets should retain a clear way to open in another renderer/browser.

Suggested warning copy:

> **External website preview**
>
> Dormouse's iframe proxy changes website security protections to support local development. Do not sign in or enter sensitive information here.

Avoid claiming that every external page is necessarily vulnerable to XSS. The concrete concern is that proxy rewriting changes browser protections; allowing an origin does not make authenticated use safe.

## Cookie support: defer until real tools require it

Do not add a cookie jar, cookie emulation, per-proxy IP allocation, or authenticated external browsing in this issue. Native JavaScript cookies on the shared loopback hostname remain a documented limitation; an allowlist is not cookie isolation.

As actual local tools fail, capture the tool/version, host/platform, reproduction, expected workflow, and the cookie behavior needed (server-managed session, JavaScript cookie access, CSRF, WebSockets, etc.). Use those stories to define a separate cookie enhancement and its compatibility tests.

A future jar must address caller authorization before attaching stored credentials. Restricting upstreams to localhost does not by itself prevent an unrelated caller from using a logged-in proxy session.

## Implementation references

- `docs/specs/dor-browser.md` — iframe renderer and target policy
- `docs/specs/security-local.md` — browser-pane and loopback-listener boundaries
- `lib/src/host/iframe-proxy.ts` — target handling and redirects
- `lib/src/host/iframe-proxy-rewrite.ts` — injected navigation reporting

Update the owning specs when implementing the enhancement. Validate the warning/allowlist in both hosts, including initial navigation, cross-origin transitions, cancellation, and preserved local-tool behavior.

Start with docs/specs/dor-browser.md and docs/specs/security-local.md, then trace target handling and redirects in lib/src/host/iframe-proxy.ts and navigation reporting in lib/src/host/iframe-proxy-rewrite.ts. Establish enforcement in both VS Code and Tauri before choosing the mechanism. Done means local loopback behavior remains intact while external navigation is gated by a removable exact-origin allowlist and warning, with the owning specs updated.

Written by the indexing model from the issue text.