Write a live goal and the score it makes in one commit, not two

[JaspervdM80]

Closes #61.

Logging a goal at the touchline inserted the row through GameService and then recounted the
scoreline through MatchGoalService's own context. Two contexts are two connections, so those were
two transactions with a gap between them — and a SQLite lock timeout, a failure on the second save,
or Fly.io restarting the container mid-deploy all land in it, leaving the goal on file behind a
stale score. Removing a goal had the same shape.

GameService does both halves itself now. AddGoalAsync and RemoveGoalAsync take
recountScoreline; when it is set they open a transaction, save the goal, recount the scoreline
from the goals then on file, and commit the two together. MatchGoalService keeps the one thing
only a live match knows — the minute the clock showed — and delegates the rest, so goal storage
still has a single implementation and no context is passed between services. That avoids both
options #61 called non-trivial: no context or transaction crosses a service boundary, and goals are
not stored twice.

The recount deliberately runs after the save rather than before it, even though counting in memory
ahead of the insert would fit both writes into a single SaveChanges. That shape is a
read-modify-write on a row with no concurrency token: two admins on the same live match — the thing
LiveMatchNotifier exists for — would each read n goals and each write a scoreline of n+1.
Counting afterwards, with SQLite's write lock already held, makes the second one wait and then count
both. The first commit here had it the tidier, wrong way round; the second fixes it, and
known_issues.md now names the trap so it does not get "simplified" back.

recountScoreline defaults to false, which is the result page: there the score is typed by hand and
the goal list is allowed to be shorter than it, so recounting would rewrite a 3-1 as 1-0. Both
behaviours are pinned by tests. Game.CountScoreFrom is the recount this and the final whistle now
share, and it stays a recount rather than an increment — a score derived afresh from the goals
repairs itself.

Two related decisions from the ticket are settled in writing rather than in code, which #61 allowed
for explicitly. Creating a game may still save a season before the game, in SeasonService's own
context; the leftover is an empty season, which is a valid gapless window that the next game on that
date resolves to and reuses, and a test pins that reuse so the reasoning holds rather than merely
being believed. And the seeding insert in MatchPreferencesService.GetAsync — the one read in the
app that writes — now saves with CancellationToken.None, so navigating away cannot cancel a write
the rest of the app treats as having happened. The lookups above it stay cancellable. Writes still
do not take the page-lifetime token, which #61 ruled out and this does not revisit.

docs/patterns.md gains the rule and both accepted exceptions, docs/known_issues.md the two traps
(a transaction cannot span two AppDbContext instances; collapsing the goal write into one save
reintroduces a lost update), with models.md and architecture.md following the code.

Checked: dotnet build -c Release clean, dotnet test 406/406, scripts/coverage.sh 100% of
changed lines (34/34), cd tests/ui && npm test 39/39. The atomicity property is invisible from
outside until something interrupts the halves, so MatchGoalServiceTests counts commits through a
transaction interceptor; I verified that counter is not vacuous (two sequential goals give two
commits, not one per save).

No migration, and nothing here changes what an anonymous visitor can see — every touched write
already went through RunAdminAsync, and the one read that changed (MatchPreferencesService) is
reached only from admin-only callers.

🤖 Generated with Claude Code

https://claude.ai/code/session_013ys63zAujLcoaS7UP9F2wm