Release v4.37.0

Added

• Event generations now bind to the executable model. Events with several generations share one contract identity and carry their complete prior revisions, predecessor links and revision-specific property identities. Ordinary references use the current generation. This implements decisions 0011 and 0015 and advances #71.
• Persisted event contracts can advance through an explicit, catalog-revision-checked workspace transaction. Renaming or moving an event preserves its identities across generations; combining a rename with evolution still requires explicit advancement.
• The RegisterProject v2 canonical corpus declares two event generations, removes the duplicated projectId from the current event payload and uses the event source as its identity. Single-file, folder, reordered and relocated forms produce the same model. This advances #168.

Changed

• Models with multiple event generations select ESM v4. A lone generation 1 keeps its previous ESM version, and v1–v3 canonical bytes are unchanged. Consumers must explicitly admit v4 before accepting these models; generation transformations, historical replay and Chronicle deployment support remain separate work under #71.
• ESM v4 no longer serializes projection-transition cardinality and rejects the legacy ZeroOrOne and Many values. Query cardinality is unchanged (decision 0007; part of #132).
• References to removed current-generation properties fail binding instead of falling back to historical shapes. MCP understands generation-qualified addresses and exports canonical v4 models.