fix(vendor): pass request locale to query.graph on vendor routes

[vholik]

Problem

Closes #1171

Medusa 2.17's Translation Module resolves translated fields only when a locale is passed as query.graph's second (options) argument. The vendor panel's API routes call query.graph({ ... }) without the options argument, so no locale signal ever reaches the query — sellers always see base-language content even when translations exist and the store's supported_locales are configured.

The framework only registers its locale middleware for the /store namespace, so req.locale is never populated on /vendor/* requests either. Both halves of the problem needed fixing.

Changes

• New applyVendorLocale middleware (packages/core/src/api/utils/apply-vendor-locale.ts), registered on /vendor/*. It resolves the request locale and sets req.locale, mirroring the framework's store-side behaviour but with the resolution order requested in the issue:
  1. ?locale= query parameter (stripped afterwards so it never leaks into filterableFields)
  2. x-medusa-locale header
  3. lng cookie (set by the vendor panel language switcher)
  4. Accept-Language header
• Forward req.locale to query.graph on the translatable catalog read routes:
  • product-categories (list + detail)
  • collections (list + detail)
  • product-tags (list + detail)
  • product-types (list + detail)
  • products (list + detail)

With req.locale now available on every vendor request, remaining routes can adopt the same pattern as needed.

Testing

Added regression coverage in integration-tests/http/product-categories/vendor/product-categories.spec.ts verifying the vendor category routes accept a ?locale query param (without it leaking into filters) and the x-medusa-locale header.

Full end-to-end translation verification (create a translation via POST /admin/translations/batch, then GET /vendor/product-categories with x-medusa-locale: ar) requires the translation feature flag enabled.