Return a non-5xx response when /first-party/sign declines a host by rewrite policy #1394

Description

When /first-party/sign declines a URL because its host matches rewrite.exclude_domains or falls outside a non-empty rewrite.include_domains, handle_first_party_proxy_sign (crates/trusted-server-core/src/proxy.rs, around line 1699) returns an Err. Every adapter's http_error then logs Error occurred: … at error level and responds 502.

A decline is an expected policy outcome, not a server error. The spec logs declines at debug for that reason, but the Err undoes it. Once include_domains is set, most ad-tech hosts are off-list, so each runtime-inserted image or iframe in a creative costs a sign round-trip that returns 502. Each one adds an error log line, a 5xx in edge metrics, and a client tsjs-creative: sign HTTP error 502 warning (proxy_sign.ts). This noise can bury real proxy failures and trip 5xx alerts.

The reviewer listed two options:

1. Return the decline as Ok with a response built in the handler, which skips http_error's error log. (Suggested starting point.)
2. Use a 4xx status such as 422 for policy declines. proxy_sign.ts already falls back to a direct load on any status other than 403, so 5xx stays reserved for real upstream failures.

Related: #430 covers other client-caused proxy failures that return 502.

Done when

• An exclude_domains / include_domains decline returns a non-5xx response from the handler (Ok with an explicit status) instead of an Err.
• The decline is logged below error level.
• docs/guide/api-reference.md, docs/guide/first-party-proxy.md, and the JS client handling in proxy_sign.ts are updated in the same change.
• proxy_sign_rejects_excluded_urls and related tests assert the new status, and the handler's # Errors docs mention the decline.

Affected area

Core (Edge Cookies, GDPR)

Context

From aram356's review on #1253 (crates/trusted-server-core/src/proxy.rs, around line 1699).