Release v4.27.0

Validation written as code now binds to the executable semantic model instead of being rejected. This is the second implementation-attachment role from decision 0002, after reducer transitions; it removes the code-validation blocker tracked in #209.

Added

• A named rule with a csharp body or a file on a command property or a concept (invoiceNumber rule BeUnusedInvoiceNumber file Validations/BeUnusedInvoiceNumber.cs), and a command's validate csharp block, bind as opaque rule-predicate and code-validation attachments. Each carries what it guards, its message (including $strings keys) and severity, a stable requirement id and the capability pure. A bare named rule with neither body nor file is still rejected.
• SemanticCodeValidation, SemanticCommand.CodeValidations, SemanticValidationRule.Name and SemanticValidationRule.RequirementId, and the SemanticValidationRuleKind members RulePredicate and CodeValidation.

Changed

• ESM v3 now means "ESM with implementation attachments": a model is v3 when it has a reducer with a body or code validation. Models with neither keep their v1 or v2 bytes exactly.
• The reference evaluator cannot run code validation. Executing a command guarded by it, directly or through a concept on one of its properties (including inside composite types and collections), reports an unsupported outcome naming the command or concept and the rule, and a specification that runs it never passes. Authorization is still evaluated first, so a then denied specification on such a command keeps working. Specifications that do not run the command are unaffected.
• A model with two validation attachments sharing a requirement id is rejected, as duplicate reducer transitions already were.

Fixed

• An ESM v3 model (released in v4.26.0 for reducers with a body) lost v2 execution semantics: produced facts carried no event-source context, so then <Event> for … assertions failed, and a mismatched typed when … for was not rejected. v3 models now execute with all v2 semantics, as documented.