Premier League Predictor: FastAPI & PostgreSQL — Chapter 8, Exercise 3
====================================================

TASK
Record and score predictions from all four sources across at least two
fixtures, where one fixture has two guests and the other has only one,
then call GET /api/seasons/{id}/prediction-table and confirm the guest
row's predictions_scored equals 2, not 3.

SOLUTION

Using two real fixtures in the same season:

Fixture A (two guests):
  - user, expert, ai: one prediction each.
  - guest "Micah Richards": a prediction.
  - guest "Jamie Carragher": a second, separate prediction.
  - Enter a real result via PATCH /api/fixtures/A/result, scoring all
    five predictions.

Fixture B (one guest):
  - user, expert, ai: one prediction each.
  - guest "Alan Shearer": a single prediction.
  - Enter a real result via PATCH /api/fixtures/B/result, scoring all
    four predictions.

Across both fixtures there are three individual guest Prediction rows
in total (Micah Richards and Jamie Carragher on Fixture A, Alan Shearer
on Fixture B) — but only two fixtures that had any guest prediction at
all.

Calling GET /api/seasons/{id}/prediction-table and checking the row
where source is "guest": predictions_scored should read 2, not 3. This
is because guest_per_fixture groups by fixture_id first — it produces
one row per fixture with a guest prediction (Fixture A's own averaged
figure across its two guests, and Fixture B's own single guest's
figure standing alone as its "average" of one value), and
guest_totals' own COUNT(*) counts THOSE per-fixture rows, not the
original three individual guest predictions.

This confirms directly that predictions_scored for guest means "how
many fixtures had a scored guest contribution," not "how many
individual guest predictions were recorded" — exactly the distinction
this chapter's own tip-box described, verified here against real data
rather than only asserted.

WHY THIS WORKS AS AN ANSWER
----------------------------
It deliberately constructs a real scenario with an unequal number of
guests per fixture (two on one, one on the other) specifically to make
the individual-predictions-vs-fixtures-scored distinction observable,
then correctly predicts and explains why the result is 2, tracing it
back to guest_per_fixture's own GROUP BY fixture_id.