fix(executors): DuckDuckGo ERR_BN_LIMIT without blind retry + proxy pool support

[oyi77]

What

Two fixes for the DuckDuckGo AI Chat provider:

1. ERR_BN_LIMIT (418) — no blind retry

When the chat endpoint returns 418 with an ERR_BN_LIMIT error type (DuckDuckGo rate-limit/ban on the current IP/anonymous session), the executor now returns the error immediately instead of burning another VQD acquisition on a retry that cannot succeed. The wasted retry only counts further against the IP's rate limit.

418 ERR_CHALLENGE (unsolved/expired challenge) keeps the existing one-retry-with-fresh-VQD behavior unchanged.

2. Proxy pool / session pool support

Added poolConfig to the duckduckgo-web registry entry so the provider participates in the session-pool system (fingerprint rotation + cooldown/success reporting), matching the executor's own pool settings. Combined with a per-connection/provider/global proxy assignment — which already flows through runWithProxyContext around every chat execution — a DuckDuckGo connection can now be routed through a proxy pool, rotating egress IPs to work around ERR_BN_LIMIT at the source.

Why

Reported error:

[418]: DuckDuckGo AI Chat anti-abuse challenge failed: ERR_BN_LIMIT (f46c). Retry later or from a less rate-limited IP; DuckDuckGo is rejecting this anonymous session.

The old code retried once on any 418, which is wasteful for a hard rate-limit ban. And the provider had no session-pool declaration, so it could not be assigned to a proxy pool.

Tests

New tests/unit/duckduckgo-bn-limit-418.test.ts (2 tests):

• ERR_BN_LIMIT → returns 418 immediately, exactly 1 call to STATUS_URL (no retry)
• ERR_CHALLENGE → retries once with fresh VQD, exactly 2 calls to STATUS_URL

Existing DuckDuckGo suites (VQD 429 misclassification, web executor, challenge solver regression, domain consistency, model catalog) all still pass.