[rekram1-node]

Problem

webfetch checked the URL rules for the URL the model asked for, then let fetch follow redirects on its own. So a webfetch deny rule (or a policy that only allows certain hosts) didn't apply to wherever the page redirected.

Change

webfetch now follows redirects itself and checks each new URL against the rules first. It never prompts for a redirect, it only stops when a rule denies the target.

fetch url (asks as before)
  302 → next url
    rules deny next?  → stop, "Permission denied: webfetch"
    otherwise         → follow it
  ... up to 10 redirects

• Adds Permission.assertNotDenied: same evaluation as assert (config, session rules, saved approvals, plugin hooks) but it never asks, it only fails on deny.
• Redirects to non http(s) URLs are rejected, and chains stop after 10 redirects.
• No redirect means no change in behavior. Default setups see no new prompts.

Out of scope

A redirect to a URL that would normally ask is still followed without asking.

Verification

• bun test test/permission.test.ts test/tool-webfetch.test.ts test/plugin/permission-assert.test.ts in packages/core: 200 pass
• bun run check from the repo root: passes

---

Added by the opencode bot (AI-generated).

Related: #55232

[opencodejr]

Looks good. A redirect to a URL the rules deny is followed on the base and blocked with this change.

I couldn't run it through the TUI because the simulation backend blocks all outbound HTTP. Instead I ran a temporary test with the real fetch client and a local server where /redirect returns 302 to a denied /secret. On the base, webfetch returned the secret body. With this PR, it failed with "Permission denied: webfetch". Managed tool.use deny policies also apply to redirects, since they run through the same evaluate hook. The three test files pass (200 tests). The source type-checks cleanly with tsc; the package typecheck script can't run here because bun check isn't available.

Public API unchanged: Permission.Interface.assertNotDenied is internal to core, and the plugin, SDK, HTTP API and config are untouched.

No blocking concerns.

Related: #55232