Acceptance test: rebuild colormefun on the four products

The hospital site is the easy acceptance test. colormefun is the hard one, and it is already
running in production, so it can be checked rather than imagined.

What it is: event registration for a colour run. 12 tables, public registration for individuals
and groups, reference lookup, shirt stock, payments, QR codes, printable slips, stubs and
waivers, an admin dashboard with bulk and day-of-event operations, TOTP admin login, an email
outbox, rate limiting and an audit log.

## Free today, no code

- registrations, group batches, shirt stock, counters: runtime content types
- admin users, roles, permissions: the CMS already has them
- TOTP: `IOtpService`
- audit log: the CMS audit log
- uploads: the Files module
- email sending and the outbox: Email.Resend plus workflows
- email verification: `IEmailVerificationService`
- deployment and backups: BaryoVM, which already deploys this app

## Covered by the planned increments

- the public registration form: the Forms module, #720
- admin editing: generic CRUD plus the reference picker, BaryoDev/barakoBrew#88
- the landing and status pages: BaryoDev/barakoPress#4 and #5
- settings: the singleton flag, #719
- the registration form, status lookup and printable slip as page components:
BaryoDev/barakoPress#6

## Genuinely custom, and this is what a module is for

- Reference generation, `CMF-2026-K7QM-00843`: a sequential counter with a random middle segment,
allocated inside the write transaction. `BarakoCMS.Accounting/JournalEntryHook.cs` already does
exactly this for EntryNumber, so the pattern is proven rather than speculative.
- The lookup guard: reference plus last name, with attempt throttling. A module endpoint.
- Group batching.
- QR codes and print layouts: press components.
- Excel export: Portability, or a module endpoint.

## Where the four products would not help, and that is worth saying

The day-of-event operations dashboard. barakoBrew is generic CRUD, and that screen is bespoke UX
under time pressure. It would still be built by hand, either as a console screen or as a gated
page of widgets once BaryoDev/barakoPress#7 exists.

## The verdict

Roughly the plumbing comes free: auth, roles, audit, email, uploads, files, backups, deploys, and
the twelve tables become content types. What stays is one module holding the domain rules, a
handful of page components, and one bespoke admin screen.

That is a real reduction rather than a rewrite in disguise, and it is a better test of the
architecture than a brochure site because it has invariants, public writes and printable output.
Worth rebuilding once the increments in #722 land, as the proof the pitch is true.

Start by reading the dependencies named in #722, #719, #720, and the linked barakoPress and barakoBrew issues, then inspect BarakoCMS.Accounting/JournalEntryHook.cs for the reference-number pattern. Compare the colormefun requirements with the existing CMS capabilities and identify the remaining custom module, page components, and operations dashboard. Done means the rebuilt acceptance test runs on all four products and demonstrates the stated domain rules and outputs.

Written by the indexing model from the issue text.