Define UTC event time and preserve POS timestamp provenance #1991

Problem

The processor represents the terminal-reported event time as DateTime throughout its API, aggregate, domain events, and transaction model. The database schema stores it as SQL Server datetime2, which does not retain a UTC offset or zone. This leaves the processor without an explicit contract for whether the value is UTC or the POS's local wall-clock time, and prevents reliable reconstruction of the POS-reported time once the offset is dropped.

Relevant locations:

• TransactionProcessor.DataTransferObjects/DataTransferObject.cs: TransactionRequest.TransactionDateTime is a DateTime, described as when the transaction occurred at the terminal.
• TransactionProcessor.BusinessLogic/Requests/TransactionCommands.cs, TransactionProcessor.Aggregates/TransactionAggregate.cs, and TransactionProcessor.Models/Transaction.cs: event time remains DateTime.
• SQL Server migrations persist TransactionDateTime in datetime2 columns.

Desired behavior

Define and implement a clear processor contract for event time and host time:

• Preserve the POS-reported timestamp and offset (and a store/POS zone ID if required for audit or local business-day calculations).
• Store and use a canonical UTC instant for host-side ordering, processing, and cross-service communication.
• Record host receipt/processing time separately in UTC; do not substitute it for the POS event time.
• Derive store-local reporting/trading dates from the UTC instant using the configured store time zone, rather than from the service host's local zone.

Proposed changes

• Coordinate the request contract with the POS and ACL changes so transaction timestamps arrive with an explicit offset; reject offset-free event timestamps instead of inferring a zone.
• Use DateTimeOffset at the API/boundary where the POS offset must be preserved, then normalize the canonical event instant to UTC before domain processing and persistence.
• Decide how to retain the source timestamp/offset and optional zone ID for audit. Keep this provenance distinct from the canonical UTC event time.
• Keep transaction event time separate from host receipt/creation time, and ensure host-generated timestamps use UTC.
• Review projections, statement/day grouping, and reporting filters so store-local business dates use the configured store zone.
• Add a migration/backfill strategy if new provenance fields or changed storage semantics are required; define how existing datetime2 rows are interpreted.

Acceptance criteria

• The API contract requires an explicit offset for POS transaction event timestamps.
• The processor can persist and return the correct UTC instant regardless of the service host's configured time zone.
• POS-reported wall time/offset (and zone ID if part of the contract) remains available for audit where required.
• Host receipt time is separately available and UTC.
• Daily reporting and statement grouping use the configured store time zone at day boundaries, including daylight-saving transitions.
• Tests cover multiple offsets for the same instant, offset-free input, host timezone independence, and local business-day boundaries.
• Existing data has an explicit, reviewed interpretation/backfill plan.