Encode single-rule constraint in model, not view (architecture)

[wiseelf]

From architecture review 2026-07-19, candidate C4 ("Worth exploring").

Problem

OnCallStore.rules: [RecurrenceRule] is a real array and OnCallBilling correctly loops over all rules, but the product only ever allows one active rule — a constraint enforced only by hiding the "add rule" button in ScheduleTab.swift once store.rules is non-empty (and read via store.rules.first throughout).

Files:

• Sources/TimeTracker/OnCallStore.swift
• Sources/TimeTracker/ScheduleTab.swift:31,40,100,145,149,175
• Sources/TimeTrackerCore/OnCallBilling.swift:86-90

Solution options

• Make OnCallStore.rule: RecurrenceRule? a singleton if multi-rule support isn't planned, or
• Promote the "at most one" constraint to a store-level guard if multi-rule is a future goal

Either way, the constraint should live where the data lives, not in a button's visibility condition.

[wiseelf]

Investigated. Confirmed the issue as described — store.rules is only ever read via .first in ScheduleTab, enforced solely by that add-button's visibility condition.

Two viable fixes:

• Store-level guard, keep the array — OnCallStore enforces at-most-one internally (e.g. setRule(_:) replaces instead of appends); OnCallBilling/ReportGenerator/StatsView signatures stay untouched since they already accept [RecurrenceRule].
• Collapse to rule: RecurrenceRule? — cleaner model, but changes OnCallBilling's public signature and ripples into ReportGenerator/StatsView/tests.

Holding off on either until #38 is brainstormed: one of its candidate fixes ("soft-delete/archive the rule" to preserve historical billing) would need somewhere to keep a past rule around after it's no longer active. A strict singleton has no room for that; keeping the array does. Picking a shape here before #38 is resolved risks locking in the wrong one.