Release v20.60.0

Added

• New ICommandExecutionScope extension point — implementations are discovered automatically and participate in every command's execution, beginning before the command runs and completing exactly once, in isolation, with the final CommandResult.
• Documentation for transactional commands and command execution scopes.

Changed

• Every model-bound command now runs in a transactional scope. The events a command returns from Handle() — and appends made through the explicit eventLog.Transactional style — commit atomically when the command succeeds and roll back if it fails for any reason, in both the all-in-one AddCratis setup and AddCratisArc().WithChronicle(). Constraint and concurrency violations from the commit surface on the CommandResult, attributed to the offending member so a form can attach the message to its field.
• Appends through an injected IEventLog behave identically to IEventStore.EventLog and every other event sequence — immediate and final, returning the real AppendResult — and are never silently swallowed: a failed immediate append during a command fails the command. Previously such a failure could be discarded, leaving the command reporting a false success.

Fixed

• An unknown sortby field on a MongoDB-backed query now degrades to unsorted results instead of failing with an HTTP 500, matching the Entity Framework Core provider's behavior.
• A failure while completing a command's transaction — for example the event store being unreachable at commit — now surfaces as an exception outcome on the CommandResult instead of escaping as a raw exception to programmatic callers.