Premier League Predictor: Astro — Chapter 4, Exercise 2
====================================================

TASK
Explain why usedTeamIds is described as "convenience, not the real
rule," and describe exactly what happens — on both the client and the
server — if a stale page somehow submits a fixture for a team that's
already been used in that gameweek.

SOLUTION

usedTeamIds is a plain JavaScript Set that lives entirely in the
browser tab's own memory. It starts empty the moment the page loads
and is only ever added to as fixtures are actually created during
that same visit — it has no way of knowing about fixtures that were
already entered in an earlier visit, by a different browser tab, or
before the page was last reloaded. That's exactly why it's "convenience,
not the real rule": it exists purely to gray out buttons quickly in the
common case, not to guarantee correctness.

Concrete scenario: an admin enters several fixtures for a gameweek,
then reloads the page partway through (or opens a second tab to the
same page). usedTeamIds resets to empty in that reloaded tab, so every
team button — including ones already fixtured in the real, saved data
— re-enables and becomes clickable again.

What happens if that stale page is then used to submit a fixture
reusing an already-fixtured team:

  - On the client: nothing stops the request from being sent. The
    button was re-enabled, the two teams get selected into the Home
    and Away slots exactly as if they were genuinely free, and
    clicking "Add Fixture" fires the real POST request.

  - On the server: the fixture route re-queries every existing
    fixture for that exact gameweek from the database itself,
    independent of whatever the stale client believes. It finds the
    already-used team in that real, current list and returns a 409
    with "One of these teams is already fixtured this gameweek." No
    duplicate fixture is ever created.

  - Back on the client: the fetch call's own res.ok check catches the
    non-2xx response, reads the JSON error body, and shows it via
    alert(error.error) — the admin sees exactly why the request was
    rejected, even though the stale page's own UI never warned them
    in advance.

WHY THIS WORKS AS AN ANSWER
----------------------------
It explains precisely why the client-side Set can go stale (no
knowledge of state outside its own page load), gives a concrete
scenario that produces a stale state, and traces the real outcome
through both the client and the server rather than asserting only
that "the server catches it."