feat: swap fixtures/table/results to matchday API for leagueId-backed teams - #841

… teams

Implements #818, scoped to teams with matchday.leagueId set (only
under-12-girls today, per plan). matchService.ts/tableService.ts now
branch per-team: matchday API when leagueId is present, unchanged
local JSON otherwise. Every other team renders identically to
current prod - confirmed via a full production build.

New services (src/lib/matchday/): matchdayClubService (joins
/teams + /clubs since fixtures/table only carry team ids),
matchdayMatchService (fixtures + next/previous match resolution),
matchdayTableService, matchdayLeagueMetaService (competition/season
names), matchdaySiteConfig (matchday-equivalent of wscClubDriblId).
All cache()-wrapped since layout.tsx + page.tsx both call these per
request - unwrapped, this would have doubled real API calls per page
view for a matchday-backed team.

Also: added postponed/cancelled fixture status handling (MatchCardMobile,
MatchCardDesktop, calendar route iCal STATUS), and fixed the calendar
route's "which fixtures are ours" filter, which used the hardcoded
Dribl club id and would have silently returned an empty calendar for
matchday-backed teams.

Verified fixture/next-match/previous-match/table mapping directly
against the real matchday API (bypassing Sanity). Browser verification
of the actual team page is pending the user's Studio save.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01A7Ugh6hzUpfDpWCDnK82cc

Cleanup requested during review of the #818 changes - the matchday
service files mixed I/O (fetch+map from the matchday API) with pure
functions (filter/sort already-fetched data) in the same modules,
and matchdaySiteConfig.ts didn't fit its own folder's naming
convention (it reads Sanity, not the matchday API).

- getMatchdayClubId() moved into lib/content/siteSettings.ts, next to
  getSiteSettings() which it wraps - deleted matchdaySiteConfig.ts.
  leagueOptionService.ts now reuses it instead of re-extracting
  siteSettings.matchday.clubId itself.
- resolveMatchdayNextMatch/resolveMatchdayPreviousMatch (pure - no
  fetching) moved out of matchdayMatchService.ts into a new
  matchResolverService.ts. matchdayMatchService.ts now only does
  fetch+map (getMatchdayFixturesForLeague).

No behavior change - reverified fixture/next-match/previous-match/
table mapping against the real matchday API after the move.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01A7Ugh6hzUpfDpWCDnK82cc

Major:
- getTeamLeagueId no longer swallows Sanity errors. A failed lookup
  was returning null, which callers treat as "team isn't matchday-
  configured" - silently falling back to (now-stale) local JSON
  during a Sanity outage for a team that actually is matchday-backed.
  Now propagates.
- Once a team's leagueId IS known, matchday API failures (fixtures/
  table) are now caught in matchService.ts/tableService.ts and
  degrade to the same null/false/empty contract the local-JSON path
  already uses on failure, instead of an uncaught rejection hitting
  the generic error.tsx 500. Extracted a private loadMatchdayContext
  helper shared by getTeamMatches/getNextMatch/getPreviousMatch,
  which also kills the 3x duplicated lookup CodeRabbit flagged.
- matchdayClubService: clubSchema.parse -> safeParse, so one
  schema-invalid club record no longer fails the whole catalog for
  every matchday-backed team's fixtures/table/calendar.
- matchdayTableService: an unresolved team no longer drops its table
  row (which left gaps in position numbering, e.g. 1, 2, 4) - keeps
  the row with a placeholder name/logo instead.

Minor/nitpick:
- Centralized fixture status strings into fixtureStatusService.ts
  (was duplicated across matchdayMatchService.mapStatus and both
  MatchCard components).
- hour12: false -> hourCycle: 'h23' for kickoff time formatting
  (ICU can resolve hour12:false to h24, producing invalid "24:00").
- matchdayRequestTimeoutMs centralized in matchdayClient.ts instead
  of duplicated across 5 files.
- Plan doc: fixed stale module path reference from the earlier reorg.

Reverified fixture/next-match/previous-match/table mapping against
the real matchday API after all changes.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01A7Ugh6hzUpfDpWCDnK82cc

…coded slugs

The homepage countdown was hardcoded to two specific team slugs
(state-league-2-men-s-north-west, state-league-2-women-s) - it only
kept working by coincidence because those happened to be the two
teams backfilled with a matchday leagueId in #818. Any other team
config would have silently broken it.

- New team.ts fields: showNextMatchOnHomepage (boolean) and
  homepageDisplayName (optional short label, falls back to the
  team's real name)
- Relabeled the existing showOnHomepage field to "Show on football
  section in homepage" to disambiguate from the new field (same
  underlying field/data, title-only change)
- New src/lib/content/homepageNextMatchTeams.ts - queries teams with
  showNextMatchOnHomepage == true, capped at 2 in the GROQ query
  itself (order asc, [0...2]) rather than fetching all and slicing
  in JS
- page.tsx now maps over 0-2 dynamically fetched teams instead of
  two hardcoded MatchCountdownSection blocks; colors assigned by
  position (first = blue, second = purple)

Rollout note: no team has showNextMatchOnHomepage set yet (new field,
defaults false), so the homepage countdown section currently renders
zero cards - verified via local dev server. Need to check the box on
the two senior teams in Studio to restore today's homepage.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01A7Ugh6hzUpfDpWCDnK82cc

…der field

The homepage countdown was ordering featured teams by the same
"Order" field used for team listing elsewhere on the site (both
senior teams share the "seniors" tab there), so a change intended
for one purpose could silently reorder the other, and the user had
no direct way to control which card shows first on the homepage
without touching team-listing order too.

Add homepageNextMatchOrder (number, only shown when
showNextMatchOnHomepage is on) - homepageNextMatchTeamsQuery now
sorts by coalesce(homepageNextMatchOrder, order), so it's
independently controllable but still has a sane fallback if unset.

Verified the query directly against Sanity before wiring it up.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01A7Ugh6hzUpfDpWCDnK82cc

- GROQ coalesce() only skips null, not empty string - an editor
  clearing homepageDisplayName to "" (rather than leaving it unset)
  would have produced a blank card heading instead of falling back
  to the team name. Switched to select() with an explicit blank check.
- Field title grammar: "Show on football section in homepage" ->
  "Show in the homepage Football section" (matches the field's own
  description wording).

Verified the updated GROQ query directly against Sanity.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01A7Ugh6hzUpfDpWCDnK82cc

Root cause of the widespread 404s on /matches and /table for every
matchday-backed team: React's cache() only dedupes within a single
page's render, but a team's /matches and /table pages are separate
static-generation passes during next build. With 17 teams now
matchday-backed, that meant the full /teams + /clubs catalog fetch
(getFixtureTeamsById) alone was repeated ~34 times in one build,
plus per-league fixtures/table/meta calls repeated across passes -
enough concurrent load to time out the matchday API. The resulting
null data then hit notFound(), which Next.js bakes into a static 404
for that route during SSG (build "succeeds", pages are just 404).

Confirmed via a live concurrency test against the matchday API
directly (30 concurrent requests, all under 1s) that this isn't a
sustained throughput/connection-limit problem - it's redundant calls,
not backend capacity.

Switched getFixtureTeamsById/getMatchdayFixturesForLeague/
getMatchdayTableForLeague/getLeagueMeta from React's per-request
cache() to unstable_cache() (Next's Data Cache, persists across the
whole build and across requests within the revalidate window).
unstable_cache is soft-deprecated in favour of the "use cache"
directive in Next 16, but that requires enabling Cache Components
(experimental.cacheComponents) - an app-wide rendering model change
out of scope for this fix. unstable_cache is confirmed still present
and functional in this Next 16.3.0 install.

getFixtureTeamsById's Map return type isn't JSON-serializable (what
unstable_cache needs to store), so the cached inner function now
returns entries as a plain array, with the public function
reconstructing the Map - no changes needed at call sites.

Verified locally: build previously logged 175 matchday timeout
errors; after this fix, zero.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01A7Ugh6hzUpfDpWCDnK82cc

Bumped matchdayRequestTimeoutMs from 10s to 30s - the last deploy
showed even a single solo request (no concurrency at all) taking
close to 20s, consistent with the Vercel build region (Cleveland US
East) and the matchday API's Neon database (Singapore) being
geographically distant. This is a latency problem the unstable_cache
fix from the previous commit doesn't address on its own - that fix
cut redundant calls (175 -> 39 timeout errors), but distinct
necessary per-league calls still need enough time to complete once.

Also fixes a real bug CodeRabbit and I both independently found in
warmEndpoint: openapi-fetch rethrows network/abort errors rather than
returning them as { error }, so an uncaught timeout on attempt 1 was
skipping the remaining retry attempts entirely. Now caught and
retried like any other failure. warmEndpoint also reuses
matchdayRequestTimeoutMs directly instead of its own separate
constant, so the two stay in sync.

Keeping build-time SSG for these routes per explicit decision - not
moving to ISR/dynamic rendering.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01A7Ugh6hzUpfDpWCDnK82cc

…tures-swap

…tures-swap

# Conflicts:
#	src/components/matches/MatchCardDesktop.tsx
#	src/components/matches/MatchCardMobile.tsx

The API now serves paged list responses, which 0.2.0 client code read as bare
arrays. Fixtures and table static generation failed for every leagueId-backed
team, and there is no JSON fallback on that path, so those pages rendered blank.

Rather than patch the cursor handling, take the endpoints v2 added:

- getLeagueTeams replaces the /teams + /clubs full-catalog fetch-and-join,
  ~6500 teams and 2.4 MB to resolve the handful one league plays
- League embeds competition/season, so league meta drops from 3 requests to 1
  and the Studio picker no longer fetches both catalogs to resolve two names
- getClubLeagues pages internally and includes divisions that never publish a
  ladder, so MiniRoos age groups now appear in the picker
- unwrap replaces the hand-rolled error checks; timeout and retries move onto
  the client, so services stop passing their own AbortSignal

Drop the unstable_cache wrappers: the API caches upstream and the catalog
fetches they compensated for are gone. They were also what pinned these routes
to a 5m revalidate, so set 3600 explicitly on the team and home routes, which
render live fixtures. React cache() keeps per-render memoization, since a
team's layout and page both resolve fixtures and the table.

Delete the warm-up script. Calls are fast enough that pre-warming the Neon
compute no longer earns its place in the build.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014FyRvR326ZUNUwBZw3kTgp

The work it tracked is done, and plans are not kept in the repo.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014FyRvR326ZUNUwBZw3kTgp

Several doc comments restated what the code said or explained history that
belongs in the commit log. Keep only the non-obvious parts: why getTeamLeagueId
throws instead of returning null, why the table never drops a row, why the
client timeout is 30s.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014FyRvR326ZUNUwBZw3kTgp

Matchday team names are long enough to wrap a match card, e.g. "Melbourne
Knights FC U12 Juniors - B Female MKFC U12 Girls B". The club name alone reads
better, but it is ambiguous when a club fields two sides in the same league.

Resolve the display name over the league's team list, which is exactly the
scope that ambiguity is defined in, reusing resolveTeamDisplayName from the
local-JSON path. Verified against Girls' West 12B: 12 of 14 entries shorten to
the club name and only the two Avondale sides keep their team names.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014FyRvR326ZUNUwBZw3kTgp