feat(api): accept a result proven by two check-ins instead of an operator

[patrick-hermann-sva]

Stacked on #326 (fob resolve, which creates the check-ins this cites). Once #326 is merged I rebase this onto main; until then the diff against main shows both.

Builds the operator-free half of #320 as ADR-0024 decides it. Auto-accept is not in here (see below).

What changes

POST /api/results takes two check-ins instead of an operator.

{"home_id": "…", "away_id": "…",
 "home_checkin_id": "…", "away_checkin_id": "…",
 "sets": [[11, 9], [11, 7]], "best_of": 3, "points_to_win": 11}

The ids are the checkin_ids that POST /api/identities/rfid/resolve returned. Accepted only if:

Rule	Refusal
both ids present and different, no operator_id alongside	400
both check-ins exist	422, names the id
home's check-in is home's, away's is away's (swapped is refused)	422
the two are at different halves (which half is home's does not matter)	422
neither is older than checkin.Validity = 3 h	422
neither already carries a result	409, so a Zählwerk retrying after a lost answer learns the first copy arrived

The operator path is unchanged; without check-ins operator_id is still required.

The match is stored pending, entered_via = 'checkin', reported_by null, home_checkin_id/away_checkin_id set. Either player confirms (scoring.load already allows every participant who is not the reporter).

Schema (20261015090000, additive):

• entered_via accepts 'checkin'
• reported_by drops NOT NULL, with check (reported_by is not null or entered_via = 'checkin')
• two FK columns to checkins, with a CHECK that they are set exactly on checkin rows (each one separately)
• partial unique indexes on each

CheckinRepository.Lock reads both check-ins for update, in id order, and then asks in a separate statement whether a match cites them. A separate statement is needed because under read committed, a statement that waited for the lock still sees its old snapshot.

One trap fixed on the way. PendingFor/PendingCountFor filtered with reported_by <> $1. For a null reporter that is null, so the match would have reached neither player. It is now is distinct from.

Pending list. A match without a reporter reads „Das Zählwerk hat eingetragen: 2:1 für Anna“. The loss case now credits the opponent, not the reporter. That was also wrong for kiosk and scoreboard results, whose reporter is the operator („3:1 für “). /admin labels the origin „Zählwerk, angemeldet“.

Measurement. definition-of-done.sql gets an "of which checkin" column. The verdict already counts only entered_via = 'player', so these rows stay out of it, as ADR-0024 asks. schmetterpause_matches_open exports entered_via="checkin", zero included.

Verified

• go test -race ./... green, golangci-lint v2.14.0 0 issues, task ci (Dagger) green locally, including verify against the built image.
• Postgres integration tests on postgres:17-alpine: round trip, both players see the match in PendingFor, the schema refuses a reporter-less player row, a checkin row without check-ins, one check-in on a player row, and check-ins on a scoreboard row; Lock marks used ones; reuse → ErrConflict.
• The two guards fail without their fix. With <> restored, TestACheckedInMatchHasNoReporterAndCitesItsCheckins fails (PendingFor(Anna) = 0). Without for update, TestTwoResultsCannotShareACheckin fails: three of four concurrent transactions run into the index. The test had to be made to overlap (200 ms between read and write) before it could tell the two apart. Its first version passed either way.
• The migration's Down then Up, in a rolled-back transaction on an empty database.
• definition-of-done.sql runs and shows the new column (empty database, so syntax and shape only).
• End to end through the routes in internal/server/checkin_results_test.go: two fobs linked and resolved at both halves, the result posted, both players' pending lists show it, Bea confirms, the match is confirmed.
• Screenshot of the pending entry at 390 and 1000 px, no horizontal overflow (scrollWidth = clientWidth).

Not verified: nothing ran against a real Zählwerk. zaehlwerk#92 and zaehlwerk-firmware#63 are not built, so DoD point 3 of #323 (a checked-in match on the office's instance) is still open. The migration has not run against a copy of production data. It touches no rows, but the new CHECK constraints are validated over all existing matches, and every existing row has entered_via ≠ checkin with null check-in ids, which satisfies them.

Left open, deliberately

• Auto-accept. ADR-0024 leaves it to its own decision. Results from checked-in matches: no operator needed; pending by default, auto-accept as a setting #320 keeps it as a checkbox, so this PR says Refs #320, not Closes.
• The phone check-in. Only the fob creates check-ins so far. ADR-0024 counts a signed-in phone as proof too. That path needs its own design (one route with two proofs, or a second route), noted in Phase 6: players check in at the table, the app is findable, the mascot becomes theirs #323.
• "The result view shows how each side checked in (audit)" from Results from checked-in matches: no operator needed; pending by default, auto-accept as a setting #320. The data is there: the match points at both check-ins with half, method and time. No page shows it yet.
• Decided by the maintainer: 3 hours of validity, the pending line „Das Zählwerk hat eingetragen:“, and the admin label „Zählwerk, angemeldet“.
• Several tables (Several tables: record, schedule, book — in three stages, once a second table stands in the office #280). Once there is more than one, both check-ins also have to be at the same table. Nothing here takes a table_id yet, as in feat(fobs): link a key fob in a window and resolve it for the Zählwerk #326.

Refs #320, #323, #326

🤖 Generated with Claude Code

[patrick-hermann-sva]

Superseded by the PR opened from the same branch against main; this one was closed automatically when its base branch was deleted.