perf(appstore): optimize apps.json processing and reuse stale cache on refresh failure

[joshtrichards]

Summary

Improve appstore refresh performance and resilience by reducing work in the hot path, avoiding unnecessary cache I/O, and reusing stale cached data when refresh fails.

Changes

• refactor AppFetcher::fetch() to:
  • reuse a single VersionParser
  • memoize parsed platform/PHP version specs
  • select the best compatible release in a single pass
  • avoid temporary arrays and per-app sorting
• clean up Fetcher::get() to:
  • return processed data directly after writing cache content
  • avoid immediately re-reading and decoding the just-written cache file
  • return stale cached data instead of [] when a refresh fails and a previous cache exists
• tests
  • adjust to anticipate stale caching response behavior change
  • adjust to no longer expect reading data back from storage immediately after writing it
  • expand appfetcher coverage to include "highest compatible version wins"

Why

The appstore feed is large (~27 MB raw in local benchmarking), while the processed cache is much smaller (~3.4 MB). Most of the hot-path CPU cost comes from filtering and selecting compatible releases for each app. On refresh failures, serving the last known good cache is also more resilient than returning an empty app list.

Benchmarks

Local benchmarks on a real apps.json showed:

• AppFetcher processing: ~1.4x faster
• end-to-end local refresh path: ~1.09x–1.11x faster
• Note: the end-to-end number is dominated by HTTP + JSON decode, which this PR doesn't change.

Notes

This change is intended to be behavior-preserving on successful refreshes and does not change the persisted cache format.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI