Translate linkText for intsch-origin products on multibinding stores

[chrsmutti]

What problem is this solving?

TIS-707: on multibinding stores, Product.linkText is not translated to the shopper's binding locale when product data comes from the intsch client (used when shouldUseNewPDPEndpoint / shouldUseNewPLPEndpoint are on).

Root cause: intsch currently sends origin: 'intelligent-search' (kept for compatibility with 5 other origin-gated fields), so the linkText resolver's origin === 'intelligent-search' check can't distinguish it from the legacy vtex.intelligent-search-api path — which, unlike intsch, already performs the Rewriter translation server-side. intsch never does that call, so its linkText was silently left untranslated.

This PR:

• Adds a ProductOrigin union type ('intelligent-search' | 'intsch') for SearchProduct.origin instead of a bare string.
• Fixes the linkText resolver to route 'intsch'-origin products through the existing binding-translation path (via the already-existing but previously unused ignoreIndexedTranslation parameter on shouldTranslateToBinding), while leaving 'intelligent-search' behavior unchanged.
• Widens 5 sibling origin-gated resolvers (clusterHighlights, productClusters, properties, specificationGroups, itemMetadata) to treat 'intsch' the same as 'intelligent-search', since they share the same modern data shape.

This change is inert until a paired PR on the intsch platform ships, changing its response to send origin: 'intsch' instead of origin: 'intelligent-search'. Until then, origin === 'intsch' simply never matches in production — this PR is safe to merge and deploy independently ahead of that.

Design doc: specs/2026-07-10-linktext-intsch-origin-design.md
Implementation plan: specs/plans/2026-07-10-linktext-intsch-origin.md

How should this be manually tested?

Covered by unit tests in node/resolvers/search/product.test.ts (mocking origin: 'intsch' products ahead of the platform-side change). End-to-end manual testing on a multibinding store requires the paired intsch platform PR to also be deployed first.

Checklist/Reminders

• Updated README.md.
• Updated CHANGELOG.md.
• Linked this PR to a Clubhouse story (if applicable). — Linked to TIS-707.
• Updated/created tests (important for bug fixes).
• Deleted the workspace after merging this PR (if applicable).

Screenshots or example usage

Type of changes

✔️	Type of Change
✔️	Bug fix
_	New feature
_	Breaking change
_	Technical improvements

Notes

Depends on a paired PR against the intsch platform to change its origin value to 'intsch' — see the design doc's "Cross-repo dependency" section.

🤖 Generated with Claude Code

[vtex-io-ci-cd]

Hi! I'm VTEX IO CI/CD Bot and I'll be helping you to publish your app! 🤖

Please select which version do you want to release:

• Patch (backwards-compatible bug fixes)

• Minor (backwards-compatible functionality)

• Major (incompatible API changes)

And then you just need to merge your PR when you are ready! There is no need to create a release commit/tag.

• No thanks, I would rather do it manually 😞

[vtex-io-docs-bot]

Beep boop 🤖

I noticed you didn't make any changes at the docs/ folder

• There's nothing new to document 🤔
• I'll do it later 😞

In order to keep track, I'll create an issue if you decide now is not a good time

• I just updated 🎉🎉

[chrsmutti]

Paired platform-side change: vtex/intelligent-search#178 — changes origin to 'intsch' for direct Intelligent Search platform responses. This PR is inert until that one ships; the two should be coordinated for deploy order (either order is safe, but this fix only activates once #178 is live).

[vtex-io-ci-cd]

Your PR has been merged! App is being published. 🚀
Version 1.104.0 → 1.104.1

After the publishing process has been completed (check #vtex-io-releases) and doing A/B tests with the new version, you can deploy your release by running:

vtex deploy vtex.search-resolver@1.104.1

After that your app will be updated on all accounts.

For more information on the deployment process check the docs. 📖