PM-5562: Preserve aggregate Marathon Match wins

[jmgasper]

What was broken

The previous PM-5562 follow-up fixed Development totals for subtracks whose
history had no placement data. QA still found that profile totals for pops
and wleite showed 76 instead of 152 and 2 instead of 36.

Root cause

Both remaining gaps are legacy Marathon Match wins. Those history payloads
contain placement fields but are incomplete: pops has 5 history rows for 225
challenges and wleite has 87 rows for 575 challenges. None of those partial
rows records a first place, so the shared subtrack summary replaced valid
aggregate win counters (76 and 34) with zero placement wins. The prior fix only
covered histories with no placement fields at all.

What was changed

• Keep an explicit aggregate wins value authoritative for MARATHON_MATCH.
• Continue using placement-derived wins for modern tracks, preserving the
  PM-5458 stale-counter correction.
• Preserve PR PM-5562: Count rating-only history subtrack wins in track totals #2172's Development deduplication and rating-only history fixes.
• Challenge and submission aggregation is unchanged.

Any added/updated tests

• Added a getSubTrackSummaryStats regression case modeled on the pops
  payload, proving that 76 aggregate Marathon Match wins survive partial
  placement history with no first-place rows.
• yarn test:no-watch src/apps/profiles/src/hooks/useFetchActiveTracks.spec.tsx
  passes: 15 tests.
• yarn lint passes cleanly.
• yarn run build succeeds; it reports only existing repository warnings.
• Live dev API validation now computes 152 wins for pops and 36 for wleite,
  matching their API totals.

The broader profiles test command was also run: 14 suites pass, including all
PM-5562 coverage. Two unrelated baseline suites still fail for the same reasons
recorded on the prior attempt: MemberRatingCard is missing a
useProfileCompleteness mock, and MemberRatingInfoModal has a stale 2200+
expectation.