Release v19.8.1

Changed

• Generating a declaration from a stored, untyped composite-key expression takes the key type from the read model's Id schema (including nullable types), or from the child item's Id inside a children block. When the schema has no composite type it falls back to CompositeKey, and in that case the generated declaration only recompiles if the schema defines that type.

Fluent .NET projections still emit untyped composite-key expressions, so a newer client can keep targeting an older kernel. Declarations that name a composite-key type need a kernel that includes this change.

Fixed

• Composite-key expressions in projection declarations resolve on the kernel. The kernel, the declaration-language generator and the declarative code generator now share one $composite(...) parser. It accepts an optional leading key type name, and spacing between components doesn't matter. This is part of #4163.
• Malformed composite-key expressions fail with a clear error instead of resolving to a wrong key. That covers an invalid type name, duplicate or empty components, and whitespace-only content.
• Composite keys that contain characters such as -, @ or : in their mappings are now resolved as composite keys. Previously they fell through to value resolution, which could put every event into one read model instance. If a projection used such a key, replay it after upgrading. New events go to the correct instances, but the old instance stays until you replay.