fix(provider-openverse,provider-artic): respect upstream page-size ceilings

[MyPrototypeWhat]

Summary

Two providers sent page sizes their upstream APIs reject, so they failed under core's default fusion pool (fetchLimit = limit × poolFactor, up to 100).

• Openverse (images and audio): anonymous requests are limited to 20 results. Above that the API answers 401 {"detail":"page_size may not exceed 20 for anonymous requests"}, so every anonymous Openverse search with default settings failed. The provider now caps page_size at 20 when no token is configured, as the last step before the request, so providerOptions.pageSize cannot re-exceed it. With a token, behaviour is unchanged.
• Art Institute of Chicago: limit is capped at 100, the API's per-page maximum (403 {"error":"Invalid limit"} above it). Core's pool never exceeds 100, but a caller-supplied limit above 100 did.

Found while acceptance-testing @refkit/dsh-plugin in a live DeepSeek Harness session: the card showed openverse: openverse search failed: 401 on every search. Wikimedia Commons (gsrlimit=100) was probed too and accepts it.

The weekly live-smoke did not catch this because its Openverse searches request fewer than 20 items.

Verification

• New tests assert the real outgoing URL: Openverse images (no token: limit 24 → 20, 12 → 12, pageSize option 50 → 20; token: 24 → 24), Openverse audio (no token: 24 → 20), Art Institute (150 → 100, 12 → 12). They failed before the fix and pass after.
• pnpm typecheck, pnpm lint, pnpm test:run: 516 passed, 23 skipped (live smokes).
• Changeset: patch for @refkit/provider-openverse and @refkit/provider-artic.