Standardize business-record timestamps and chronological list ordering

[mforce]

Problem

Several date-based lists used a random UUID as the final sort key. Rows from
the same business day therefore had a stable but arbitrary order. A full model
walk also found inconsistent creation and update metadata across business
tables.

Final plan

• Keep farm business dates as DateOnly.
• Add PostgreSQL-stamped CreatedAtUtc to every business record.
• Add UpdatedAtUtc only to mutable records, equal to creation time on
  insert and replaced on every update.
• Use composable ICreatedRecord and IMutableRecord interfaces instead
  of base classes.
• Keep a shadow bigint GENERATED ALWAYS AS IDENTITY Sequence on lists
  that present or page insertion chronology.
• Sort using business date, CreatedAtUtc, and Sequence, preserving each
  list's existing direction. Payments intentionally remain oldest-first.
• Apply the same tuple to matching exports.
• Add interface-driven model enforcement and a repository rule for new
  tables.

Table classification

Mutable records, with both timestamps:

Accounts, FarmLogos, EggUnitConversions, Products,
ProductEggGradeMappings, DailyEntries, DailyEntryGrades, EggGrades,
EggLots, Expenses, ExpenseCategories, Flocks, InventoryItems,
InventoryLots, WaterUsages, Customers, Payments, SalesOrders,
SalesOrderItems, SalesOrderAllocations, and AspNetUsers.

Create-only records, with CreatedAtUtc only:

UserRoleAssignments, BirdMovements, FeedUsages, InventoryMovements, and
EggInventoryMovements.

Chronological tables, with Sequence:

SalesOrders, Expenses, DailyEntries, EggLots, BirdMovements,
Payments, InventoryLots, FeedUsages, WaterUsages,
InventoryMovements, and EggInventoryMovements.

AuditEvents keeps its existing OccurredAtUtc and Sequence. Identity
support tables and operational tables retain their own lifecycle policies.

Migration and review outcome

The migration reuses account-scoped, action-specific audit events for creation
and update times, including User.RoleChanged. Unknown times use the explicit
1970-01-01T00:00:00Z sentinel; an unrecoverable update time equals creation.
Database triggers own future timestamp stamping across EF, bulk, and raw-SQL
writes. Legacy sequence values are deterministic but not historically exact.

Independent Opus, Fable, and Sonnet reviews found and drove fixes for the
payments direction, the missing Sequence regression guard, the user-role
backfill, recalled model census, duplicated ordering, and migration SQL shape.
The Sequence guard was mutation-tested and fails when the key is removed.

Accepted limits: a database clock rollback can defeat the CreatedAtUtc
middle key, offset pagination is not a concurrent-write snapshot, and the
five-second migration timeout bounds lock acquisition rather than execution.

Implementation: #820

[mforce]

Linking the trail: the symptom that led here is #818 (an E2E spec expecting a just-created order on page one), fixed in PR #817 by scoping the lookup to the customer — which sidesteps the ordering rather than correcting it. The prior art for the remedy is #508.

[mforce]

Final load and migration rehearsal

I discarded the first measurements because another local test was contending
for the host. These are clean reruns with no other test/build job active.

k6: main vs PR

Same generated 90-day fixture and credentials; k6 v2.1.0; 3 fresh-database
reps per commit; each rep used 2 warm-up VUs for 20s, then all 10 cast users
for 2 minutes.

Capacity median	main f769681	PR eabae19	Delta
requests/s	10.930	10.947	+0.15%
p50	4.03 ms	4.20 ms	+4.2%
p95	11.13 ms	11.36 ms	+2.0%
p99	65.08 ms	73.96 ms	+13.6%
iterations	643	637	-0.9%
app CPU median	10.3%	10.2%	-0.1 pp
app memory median	230 MiB	249 MiB	+19 MiB

All 6 reps passed: 100% checks, zero unexpected statuses, all five personas
and all ten distinct users covered. The uncapped co-located harness is a
relative shakeout, not a production sizing result. The throughput and p50/p95
changes are within the observed local spread; there is no demonstrated
capacity regression. PR database size starts about 0.5 MiB higher from the
new columns/indexes; per-run growth remained 0.3-0.4 MiB on both commits.

In-place upgrade rehearsal

I then created main's 16-migration schema, seeded its full 90 days of
activity, and applied the PR migration to that same database.

• Exactly one migration applied; DDL took about 0.45s (3.23s including the
  one-shot container startup).
• Exact row counts for every public table were unchanged.
• The old serving binary remained ready (/health/ready 200) after migration.
• 17 migrations present; zero invalid constraints; zero invalid/unready
  indexes.
• Exactly 26 CreatedAtUtc columns/triggers, 21 UpdatedAtUtc columns, and
  12 GENERATED ALWAYS sequence identities.
• Every audit-derived creation/update backfill matched its account-scoped
  expected audit event across the seeded data.
• Every one of the 11 legacy sequence backfills matched its specified ranking;
  no nulls, duplicates, or lagging generators.
• A real trigger update advanced UpdatedAtUtc (then rolled back).
• The PR binary started on the upgraded database and passed the five-persona
  smoke: readiness 200, 243/243 checks, zero unexpected statuses.