fix(ep-commerce): resolve EP host when multiple global contexts share a module

[mzaintariq]

What does this MR do?

Fixes extractEpProviderConfig so it no longer takes the first host: default in a Plasmic global-contexts module. When CMS/Strapi/Shopify are nested with the EP Provider in one global__*.js, the first match was often Plasmic CMS’s https://data.plasmic.app, which the host allowlist rejects — leaving no usable EP config and breaking anonymous OAuth for storefronts that resolve credentials from the loader bundle.

Changes

• Prefer EP’s host === "custom" + customHost when present in the module
• Otherwise pick the first allowlisted concrete host
• Fall back to the first non-custom host so allowlist rejection still logs a useful value
• Regression test: CMS + Strapi + EP in one module → Fastly / customHost wins

Design decisions

• Global-contexts codegen puts many providers in one file; per-prop “first match” is unsafe for host
• EP’s distinctive shape (custom + customHost) is a reliable signal without coupling to CMS prop names
• Allowlist behavior from Security: production-guards batch — consolidates the six mechanical #279 fixes #393 is unchanged — we only choose the correct host candidate first

Testing

• Unit: existing extract tests + new shared-module regression
• Manual: Studio project with Plasmic CMS + EP Provider (custom Fastly host) — storefront session mint no longer fails with data.plasmic.app allowlist / bootstrap 401

Reviewer notes

• Independent of cart drawer designer-error work; no dependency on that PR
• Affects consumers that use extractEpProviderConfig / buildEpCtx / resolveConfig from the Plasmic bundle
• Apps that pass explicit clientId/host into createEpAuth and don’t rely on bundle extraction are unaffected