refactor(persistence): split business record census by module

[mforce]

Why

Every module had to edit BusinessRecordModel when it added a chronological table or an exclusion. This change moves those declarations beside each module's persistence configuration and merges them before the centralized census runs.

Scope

• Add BusinessRecordContribution entries for Commerce, EggOperations, Finance, FlockManagement, GeneralInventory, and Platform.
• Keep timestamp configuration, sequence configuration, and the mapped-type walk in BusinessRecordModel.
• Reject duplicate chronological and exclusion contributions with the type and contributing modules.
• Document the per-module classification rule.

No schema, migration, dependency-injection, or application behavior changes.

Blast radius

The change only reorganizes model metadata inputs. The EF model digest remains C6D126174B4508FACAEED7637A27A8C63E80F1EEE99AC24E4928056E6B0C3079, and EF reports no pending model changes.

Verification

• dotnet build Cluckwork.sln --no-restore -m:1 passed with zero warnings.
• dotnet test tests/Cluckwork.Application.Tests passed 544 of 544 before and after.
• dotnet test tests/Cluckwork.Api.IntegrationTests discovered 1,873 tests before and after. Each full run had one unrelated flaky failure. The post-change Redis timing failure passed when rerun alone.
• BusinessRecordModelTests passed 2 of 2.
• All five issue mutations produced the expected red or green result before they were reverted.

Closes #969

[mforce]

The probe exposes a pre-existing limit, not a regression in this split. ValidateCensus on origin/main also treats an IMutableRecord as classified and has no model signal that identifies tables paged or read by time. Commit c0acad3c now documents that an omitted chronological contribution stays green and requires review.

[mforce]

Review loop stopped deliberately after one round. Recording it so the silence is not read as an unfinished response.

Round 1 (Codex gpt-5.6-sol) raised one P1: a mapped, time-paged record omitted from every contribution passes the guard. That was verified against origin/main before accepting it, and ValidateCensus there behaves identically, so the finding describes a limit this slice inherited rather than a defect it introduced. Confirmed product defects introduced by this PR: zero.

The only thing in this diff the finding implicated was a sentence in the decision record claiming the walk "fixes the set of chronological tables". It does not, and that is the "a wrong guard reads as safety" failure AGENTS.md warns about, so c0acad3c replaces it with the honest limit.

No re-review was triggered, because the only change since round 1 is one documentation sentence and the reviewer has already ruled on the mechanism. Issue #969's first acceptance row asked for a red the mechanism cannot produce; that was an error in the issue and it is corrected there.

Closing the underlying gap needs an independent, fail-closed signal that a table is read by time, which is new mechanism rather than a reorganisation. It is recorded on #969 and is not in this slice.