JasperFx 2.61.0

Fixed

#733 — a self-aggregating type's constructor-based Create was dropped when ShouldDelete was present. (#735)

A self-aggregating type may declare its Create handler as an event-shaped constructor, public Foo(FooCreated e), instead of a named static Create. That worked on its own. Adding a ShouldDelete method to the same aggregate switched the source generator to a different emitter — one that built its dispatch switch from named conventional methods only — so the constructor's event type got no case arm at all.

Nothing failed loudly. The generated code compiled, the constructor never ran, and the next Apply-only event built the aggregate through RuntimeHelpers.GetUninitializedObject, skipping every field initializer. The reporter saw an ApplyEventException wrapping a NullReferenceException out of an Apply that appended to a collection property; the quieter symptom is a silently blank aggregate.

Both workarounds from the issue — converting the constructor to a static Create, or registering the delete through DeleteEvent<T>() instead of ShouldDelete — are unnecessary on this release.

The same omission was also in the generated EventTypes property on every self-aggregating path, including the ones whose dispatch was already correct. An aggregate with a constructor Create and no ShouldDelete gains its creating event in that list here too.

Verified end-to-end against Marten (JasperFx/marten#5322): the reporter's shape fails on 2.60.x across inline, async and live aggregation, and passes on 2.61.0, with EventSourcingTests (2002) and DaemonTests (319) green.

---

Thanks to @bugs-wkettlitz for an unusually complete report — root cause, emitted code, and a minimal repro.