Accounting: NumberSequence is one row under optimistic concurrency, so throughput falls as writes rise

`BarakoCMS.Accounting/Domain/NumberSequence.cs` keeps one row per named sequence and increments it under Marten optimistic concurrency. Its own comment says the loser retries.

That is correct for two editors touching the same record. It is the wrong shape for a counter that every write must increment: the abort rate climbs with concurrency, so throughput falls exactly when load rises.

Three known fixes, in order of how much they cost to adopt:

1. A Postgres sequence. Fast, and it gaps on rollback.
2. Hi/lo batch allocation per instance. Fast, and it gaps between instances.
3. Allocate the number in a serial worker at confirmation time. Gapless, and it serializes.

Gapless numbering is a business requirement in some jurisdictions and it costs serialization. Decide which is wanted before changing the code.

Not urgent at current volumes. Filed so the choice is made deliberately rather than during an incident.