MWPW-201011: Geo Promo Variations - Follow up

[Andrei4226]

Resolves https://jira.corp.adobe.com/browse/MWPW-201011
QA Checklist: https://wiki.corp.adobe.com/display/adobedotcom/M@S+Engineering+QA+Use+Cases

Bug fixes — geo-scoped promo variations:

• Fixed probePromoVariationsForFragment to probe all variation indices instead of stopping at the first missing one, previously, deleting one variation could make higher-indexed sibling variations "disappear" from Studio's promo-variation list, even though they still existed in AEM.
• Fixed getNextAvailablePromoVariationIndex to fill index gaps left by individual deletions, instead of always assuming the next index is existingCount + 1.
• Fixed createPromoVariation to force-refresh the promotions store before reading attached fragment paths, so geo-collision checks don't silently no-op when the store hasn't loaded yet.
• Fixed the tie-break logic in resolveDefaultFragmentForPromoVariation to correctly prefer the non-suffixed candidate path over a coincidentally-named suffixed fragment.
• Fixed deleteAttachedPromoVariations to delete all variations concurrently (bounded) instead of sequentially, and to throw if any deletion failed instead of silently logging and continuing.

Code quality (review follow-ups):

• Extracted a shared geoMatchScore helper, used by both the personalization (pzn) and promo-variation geo matching logic in customize.js, removing duplicated scoring formulas.
• Documented (via comments) the unavoidable duplication of MAX_PROMO_VARIATIONS_PER_FRAGMENT between the Studio and io/www runtimes (separate deployables, no shared import path).
• Deduplicated the "search + select-all + indeterminate checkbox" list UI logic shared by mas-promo-variation-geos.js and mas-translation-languages.js into a new shared module (studio/src/common/utils/selectable-list.js), with its own dedicated unit tests.
• Fixed a coding-convention issue: displayPromoVariationGeos() method converted to a getter (promoVariationGeosTemplate), matching the sibling promoVariationGeoTagsTemplate getter pattern.

Test hygiene:

• Fixed a broken test (missing loadPromotions mock on the repository stub).
• Renamed misleading test titles that still referenced the already-removed "View promo variation" UI link.

Nala test:

• Fragment: Photoshop card (Plans, NALA surface), attached to promo project NalaEvergreen
• Had 2 geo-scoped promo variations: es_AR and de and es_AR was deleted
  de promo variation: https://mas.adobe.com/studio.html#fragmentId=941b6280-0835-4b62-a8dd-bea443574264&page=fragment-editor&path=nala&promotionId=d966e2db-f2fa-4eb7-bece-a834e6c96e7e
• Test confirms the surviving de variation still renders correctly on plans-collection.html?country=DE (correct variation-id, card visible)
• Checked both with and without preview
  https://mas.adobe.com/web-components/docs/plans-collection.html?country=DE&mas.preview=off
  https://mas.adobe.com/web-components/docs/plans-collection.html?country=DE&mas.preview=on

If you want to see the de promo variation in Promotion column for the Photoshop parent fragment, please use the link of branch:
https://mwpw-201011--mas--adobecom.aem.live/studio.html#page=content&path=nala&query=9c718c8b-8807-4f2b-b41a-ae7f87d69832

About the idea to combine promotion-model.js and promotion-repository.js:

• Different purpose: promotion-model.js = pure functions, no state; promotions-repository.js = Store-aware orchestration.
• Different consumers: the former is used by 14 files across the whole studio codebase (many unrelated to promotions); the latter only by 7, strictly within the promotions feature.
• Coupling risk: aem/fragment.js (a base file, used everywhere) would become dependent on Store plus the entire promotions feature, despite having nothing to do with it — any code using Fragment would risk breaking because of an unrelated feature.

Please do the steps below before submitting your PR for a code review or QA

• C1. Cover code with Unit Tests
• C2. Add a Nala test (double check with #fishbags if nala test is needed)
• C3. Verify all Checks are green (unit tests, nala tests)
• C4. PR description contains working Test Page link where the feature can be tested
• C5: you are ready to do a demo from Test Page in PR (bonus: write a working demo script that you'll use on Thursday, you can eventually put in your PR)
• C.6 read your Jira one more time to validate that you've addressed all AC's and nothing is missing

🧪 Nala E2E Tests

Nala tests run automatically when you open this PR.

To run Nala tests again:

1. Add the run nala label to this PR (in the right sidebar)
2. Tests will run automatically on the current commit
3. Any future commits will also trigger tests as long as the label remains

To stop automatic Nala tests:

• Remove the run nala label

Note: Tests only run on commits if the run nala label is present. Add the label whenever you need tests to run on new changes.

Test URLs:

• Before: https://main--mas--adobecom.aem.live/
• After: https://mwpw-201011--mas--adobecom.aem.live/

[aem-code-sync]

Hello, I'm the AEM Code Sync Bot and I will run some actions to deploy your branch.
In case there are problems, just click the checkbox below to rerun the respective action.

• Re-sync branch

Commits

• 01b4a0c ✅ (latest)
• 01da47c ✅
• 626309c ✅
• 7fd15a7 ✅
• 3fa7125 ✅
• 913208a ✅
• 1f9a68e ✅
• 2917514 ✅
• 8f419c6 ✅
• 4d31231 ✅
• db0f9ee ✅

[codecov]

Codecov Report

❌ Patch coverage is 99.36709% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 89.90%. Comparing base (6028386) to head (01b4a0c).

Files with missing lines	Patch %	Lines
studio/src/mas-fragment-editor.js	66.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1069      +/-   ##
==========================================
+ Coverage   89.85%   89.90%   +0.04%     
==========================================
  Files         298      299       +1     
  Lines       94917    95011      +94     
==========================================
+ Hits        85287    85416     +129     
+ Misses       9630     9595      -35     

Files with missing lines	Coverage Δ
studio/src/common/utils/selectable-list.js	100.00% <100.00%> (ø)
studio/src/promotions/mas-promo-variation-geos.js	100.00% <100.00%> (ø)
...tudio/src/promotions/mas-promotions-items-table.js	97.18% <100.00%> (+<0.01%)	⬆️
studio/src/promotions/promotion-variations.js	100.00% <100.00%> (ø)
studio/src/promotions/promotions-repository.js	100.00% <100.00%> (ø)
...tudio/src/translation/mas-translation-languages.js	95.72% <100.00%> (+2.07%)	⬆️
studio/src/mas-fragment-editor.js	88.83% <66.66%> (ø)

... and 8 files with indirect coverage changes

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6028386...01b4a0c. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mirafedas]

Good job 👍

[mirafedas]

Do we need a mixin? It looks to me we could have just plain utility functions, and pass this.searchQuery as a param to filterBySearchQuery. I think it will decrease complexity (debugging mixins is harder than plain functions)

[mirafedas]

Here we will be sending up to 50 parallel requests for every variation - can we consider sending one request to get all fragments in the folder, and then filter out variations? Or some other optimization