[MBL-2992] Reward ordering

[jlpl15]

📲 What

• Fetch rewards sorted by backend eligibility (sort: ELIGIBILITY).
• Re-fetch rewards when shipping location changes (same query, no location param).
• Remove client-side reward grouping and sorting preserve backend order and only put no-reward first.
• Update related unit tests.

🤔 Why

Backend now provides the correct reward ordering (secret, featured, available, unavailable) via the ELIGIBILITY sort. we use it directly to avoid duplicating or diverging client logic and to keep ordering consistent.

🛠 How

• FetchProjectRewards – Added $sort: ProjectRewardsSort = ELIGIBILITY and rewards(sort: $sort). No location parameter backend returns eligibility-sorted list.
• getRewardsFromProject – Takes slug and optional sort (default ELIGIBILITY). No location/country code.single call used for initial load and when shipping rule changes.
• Re-fetch on shipping change – When the user changes shipping location, we still call getRewardsFromProject(slug) and rebuild GetShippingRulesUseCase with the new rewards, then apply the selected rule for filtering.
• GetShippingRulesUseCase.filterRewardsByLocation() – Uses a single list (filteredRewards): no separate groups or client-side .sortedBy(). Adds no-reward at the front when present otherwise preserves backend order and only filters by which rewards ship to the selected location.

👀 See

• Staging project: https://staging.kickstarter.com/projects/1613788818/freegan-wallet-sandwich

• Screen.Recording.2026-02-04.at.6.01.39.p.m.mov

• video with featured rewards and rewards not available

Screen_recording_20260217_154633.webm

Video demo showing rewards still ordered correctly. Note: featured badge UI will come in a future PR this one only changes sorting without breaking existing UI.

📋 QA

• Open the staging project above.
• Verify rewards list order is correct (e.g. featured/digital reward at top when applicable).
• Change shipping location and confirm rewards re-fetch and list updates (order preserved, location filtering applied).
• Ensure no regressions in reward selection flow.

Story 📖

[MBL-2992 Reward ordering](https://kickstarter.atlassian.net/browse/MBL-2992)

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 60.00000% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 64.21%. Comparing base (8dc418f) to head (531ceb2).

Files with missing lines	Patch %	Lines
...ain/java/com/kickstarter/libs/utils/RewardUtils.kt	0.00%	1 Missing and 1 partial ⚠️
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #2473      +/-   ##
============================================
- Coverage     64.22%   64.21%   -0.02%     
+ Complexity     2419     2414       -5     
============================================
  Files           384      384              
  Lines         29231    29209      -22     
  Branches       4236     4228       -8     
============================================
- Hits          18774    18756      -18     
  Misses         8189     8189              
+ Partials       2268     2264       -4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Arkariang]

Tested as well with project https://staging.kickstarter.com/projects/isabel-martin/tween-podcast-sandwich to test filtering by shipping location as the project has rewards restricted to Canada.
Seems to be working fine but there was 1 project that did not load any reward, unable to reproduce though, will require more in depth QA before releasing.

Approving as the objective of this PR was having ordering provided from the backend and changing as little as possible code. We aim to refactor soon the UseCase and VM 🙏

[Arkariang]

unsure what we ended deciding, but we were ok by not filtering and rather showing on the reward card the "unavailable" UI when shipping not available. If that's the case this entire method could potentially be deleted.

[jlpl15]

We’re going with the “no filtering” approach. I removed filterRewardsByLocation and replaced it with setRewardsList, which only keeps backend order and puts no-reward first. We always show all rewards; the reward card shows the “unavailable” UI when shipping isn’t available for the selected location. Changes are in GetShippingRulesUseCase and the affected tests.

[Arkariang]

💯
@jlpl15 make sure in RewardsUtilsTest we cover this method as well

[jlpl15]

Would cover it on future pr