fix(server): return empty list + CORS header for untrusted /permission/pending

[sanity]

Problem

Lukas Orsvärn reported (Matrix, 2026-04-14) a console error when opening a contract-hosted image viewer:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading
the remote resource at http://127.0.0.1:7509/permission/pending.
(Reason: CORS header 'Access-Control-Allow-Origin' missing).
Status code: 403.

/permission/pending was replying 403 Forbidden to any untrusted Origin header (e.g. null from a sandboxed iframe), but the 403 carried no Access-Control-Allow-* header, so the browser surfaced a "CORS header missing" error in devtools for every non-same-origin caller. The underlying behaviour (hiding live prompt contents from untrusted callers) was intentional, but the console noise looked like a real bug and made the contract-hosted webapp URL unusable without errors.

Solution

Always reply 200 OK with Access-Control-Allow-Origin: *, and return an empty [] body when the Origin is untrusted. The shell's polling loop silently ignores an empty list:

• Trusted loopback origin → full prompt list (unchanged).
• Missing Origin → full prompt list (unchanged — documented threat model).
• Untrusted / null / cross-origin → empty [] with CORS header → browser can deliver the body, no console error.

Security posture is unchanged: a cross-origin or DNS-rebinding attacker still cannot learn live prompt contents, and /permission/{nonce}/respond retains its strict Origin check independently. * is safe on this endpoint because no credentials (cookies, auth tokens) are associated with the poll.

Testing

Three regression tests in permission_prompts::tests, all asserting both body shape and presence of the CORS header:

• test_pending_prompts_untrusted_origin_returns_empty_with_cors — replaces the old test_pending_prompts_rejects_untrusted_origin and documents the new contract.
• test_pending_prompts_null_origin_returns_empty_with_cors — regression for the reported bug (Origin: null from sandboxed iframes).
• test_pending_prompts_trusted_origin_returns_list_with_cors — confirms trusted origins still see the real list and get the CORS header.

cargo test -p freenet --lib permission_prompts → 33 tests, all pass. cargo fmt --check clean. cargo clippy -p freenet --lib -- -D warnings clean.

Fixes

Addresses Lukas's Matrix report from 2026-04-14 (no issue number yet).

[AI-assisted - Claude]

[github-actions]

Rule Review: No issues found

Rules checked: code-style.md, testing.md, git-workflow.md
Files reviewed: 1 (crates/core/src/server/client_api/permission_prompts.rs)

No rule violations detected.

Summary of what was verified:

• No naked .unwrap() in production code — the new pending_prompts handler uses .unwrap_or(false) (fallible header decode → defaults to untrusted), which is correct.
• fix: PR includes regression tests — three new test functions cover the specific bug scenarios:
  • test_pending_prompts_untrusted_origin_returns_empty_with_cors (evil.com → 200 + [] + CORS)
  • test_pending_prompts_null_origin_returns_empty_with_cors (sandboxed iframe Origin: null → 200 + [] + CORS)
  • test_pending_prompts_trusted_origin_returns_list_with_cors (loopback → 200 + full list + CORS)
• Existing test updated, not deleted — test_pending_prompts_allows_missing_origin is enhanced (adds assertion on list length) rather than dropped.
• No fire-and-forget spawns, no retry loops, no biased; selects introduced.
• Code comment explains WHY, not WHAT — the large block comment on pending_prompts documents the security rationale and why 200 + [] is safe.

---

Rule review against .claude/rules/. WARNING findings block merge.