Design reusable revision timeline mechanics and apply them to monitoring rules

[carndog]

Outcome

Implement reusable business-effective revision timeline mechanics in TradingEngine.Domain and apply them first to per-instrument monitoring-rule revisions.

The same composed timeline component will later support PortfolioRiskPolicy (#49) and PerformanceObjectiveSchedule (#51) without merging their different definitions, scopes or aggregate-specific validation.

The difficult temporal invariants are proven without EF Core, SQL Server, Azure or API concerns.

Acceptance criteria

• Design a reusable generic or equivalently typed RevisionTimeline component in TradingEngine.Domain
• Prefer composition so each aggregate retains its own identity, scope, definition type and validation
• Keep persistence, XML serialization, message contracts and aggregate-specific fields out of the shared timeline component
• Represent absolute timestamps and effective boundaries with NodaTime Instant
• Represent effective periods as half-open intervals: [EffectiveFrom, EffectiveTo)
• Support the lifecycle Draft → Effective → Superseded
• Allow at most one proposed Draft successor per timeline initially
• Allow only Draft definitions to be edited or deleted
• Make the definition and revision identity immutable after activation
• Obtain the current instant through NodaTime IClock in the Application layer and pass the Instant explicitly to the Domain
• Activate a Draft by assigning the next business revision number and opening its effective period
• Close the previous effective period at exactly the successor's activation instant
• Prevent backdated activation, overlapping periods and more than one Effective revision at an instant
• Retain stable revision IDs and all Effective and Superseded revisions
• Support retrieval of the revision effective at a supplied Instant
• Keep creation time distinct from effective time
• Capture creation metadata and an optional change reason
• Return a consistent aggregate change that can later be persisted atomically
• Apply the reusable component to the monitoring-rule aggregate without weakening monitoring-specific invariants
• Add reusable timeline tests plus monitoring-rule-specific transition, boundary and effective-at tests
• Use only synthetic definitions and parameters in public tests

Clarifications

• This is shared lifecycle machinery, not one generic aggregate containing every configuration type.
• MonitoringRule, PortfolioRiskPolicy and PerformanceObjectiveSchedule remain separate aggregates with separate XML schemas.
• A PerformanceObjectiveSchedule revision contains an immutable list of dated objective periods; each period is not initially a separate revision timeline.
• Draft represents the proposed next revision; future-dated scheduling is not required initially.
• The business revision number is assigned on activation so it represents effective order.
• Business revision number, XML schema version and SQL rowversion remain distinct concepts.
• Lifecycle metadata may change only through controlled domain operations; an activated definition cannot change.

Out of scope

• EF Core and SQL Server mappings
• Database migrations and transactions
• XML serialization details
• REST endpoints and UI
• Azure provisioning