feat(scoring): carry the reason for a result through to the record

[CourtHive]

What

The scoring modal can now record why a match ended — Ret [inj] rather than just RETIRED — and TMX carries that through to the record.

The gap this closes

The engine has accepted outcome.matchUpStatusCodes for a long time: it reaches modifyMatchUpScore untouched. TMX was the one place that dropped it, building its outcome without the field, so nothing a modal offered could ever have landed.

How the vocabulary is resolved

Per event, since a scoring policy can be attached at that level, and read through findPolicy — the same call renderDraws/getActionOptions.ts already uses.

Nothing is bundled. TMX ships no built-in vocabulary by design (CA, 2026-09-20): the reason control appears only where a governing body's policy is attached, and is absent everywhere else. undefined here is the ordinary case, not a failure to defend against.

One detail that is a decision

The code is forwarded only when one was actually chosen. The factory reads an empty matchUpStatusCodes array as an instruction to blank the codes — so sending [] to mean "no reason given" would erase what a previous edit recorded.

Verified against the published resolution, not the linked sibling

This is a cross-repo boundary change, so a local green against link:../courthive-components would have proved nothing. Reproduced CI's resolution instead — overrides stripped, pnpm install --no-frozen-lockfile, courthive-components resolving to 4.5.0 from npm:

gate	result
check-types	0
lint	0
test	183 files / 2005 tests

The workspace file was then restored byte-identical and the sibling symlink is back.

Full gate also green against the linked sibling: lint / format:check / attr-audit --ci / i18n-audit --ci / check-types / test all 0.

The pin bump is load-bearing; the lockfile is not

pnpm-lock.yaml is deliberately unchanged. It records courthive-components as link:../courthive-components because the workspace override wins locally; CI strips that line and re-resolves this one entry from the package.json pin. 4.4.0 — the previous pin, and also the previously-latest published version — knew nothing of ScoringModalParams.matchUpStatusCodes or StatusCodeGroups.

Completes the series

courthive-components #571 (explicit double exits), #573 (the six policy endings), #574 (the reason-code picker) — all merged and released as 4.5.0.

Acceptance test included

Journey 126 drives the real modal end to end and asserts the chosen reason reaches matchUp.matchUpStatusCodes. Both halves are asserted, and the negative one is not a formality — "no reason control" is the state nearly every tournament is in, and a resolver that quietly returns undefined is indistinguishable from a tournament with no policy attached.

	asserted
no policy attached	control absent, result still submits
policy attached	control offers the policy's own codes; RJ lands on the record

Falsified rather than assumed: removing the single line in scoreMatchUp.ts that forwards the codes turns the positive test red at exactly expect(codes).toContain('RJ'), while the negative test correctly stays green.

Also adds a mock tournament, "Reason Codes Invitational" — the only mock carrying a reason vocabulary — so the control can be found by hand and not only by Playwright. completeAllMatchUps is deliberately off: a tournament with everything already scored has nothing to demonstrate it on.

Both take the vocabulary from fixtures.policies.POLICY_SCORING_USTA rather than restating it; a test asserting against its own copy asserts nothing about the real one.

enterMatchUpScore joins the dev bridge for the same reason fetchUserContext is there: exposing the real entry point keeps the journey on the production path, including the policy lookup that decides whether the control exists at all.

Journey 126 passes locally (2/2). Note TMX PR CI does not run the journey suite — electron.yml scopes Playwright to the desktop smoke — so that number is local-only evidence, as the standards require me to say.