Record that a contract's period and its recognition frequency together decide
how many revenue rows one activation writes, and that nothing bounded that
pair. An end date typed as 2205 instead of 2025 was accepted in full: a monthly
contract running to 9999-12-31 produced 95,712 schedule dates, each one its own
INSERT inside the activation transaction.

Note that ListRevenueSchedules carries no limit of its own and returns every row
for the contract at once, so the schedule tab — the same screen where the
mistake would be found and fixed — could never load again. The typo broke the
only place it was visible from.

Record that buildScheduleDates now refuses a period producing more than 600
entries, fifty years of monthly recognition and already far past any real
contract, and that the message says which of the two inputs to change. The check
sits in that function because both paths that write schedules, creating a
contract as ACTIVE and activating a draft, go through it, and because
ActivateContract pre-flights with the same function before opening its
transaction, so validation and the write cannot drift apart.

Record the four guards, including that the refusal stays a 400 rather than being
misclassified by serviceError's substring matching, and that removing the limit
makes them fail. No migration; rows already written are left alone.