Reconciliation scanner: null Type.FullName crash risk for generic activity types

**Severity: high | Ease: easy**

`src/Elsa/Activities/Design/Reconciliation/Clr/Services/ActivityTypeVersionResolver.cs:31` (also `ClrAssemblyScanner.cs:138`)

`type.FullName!` is asserted non-null, but `Type.FullName` is genuinely `null` for open generic types, and `IsActivityType` (`ClrAssemblyScanner.cs:149-151`) does not exclude generic type definitions.

**Failure scenario:** An author ships `public class RetryActivity : IActivity` (non-abstract, implements `IActivity`) in a scanned folder. The scanner accepts it, then `type.FullName!` yields `null`, silently propagating a null `ActivityTypeKey` into a non-nullable `string` model field — producing either a `NullReferenceException` downstream or a corrupted catalog row with key `null`.

**Proposed fix:** In `IsActivityType`, also require `!type.IsGenericTypeDefinition` (and ideally `!type.ContainsGenericParameters`), or explicitly skip+log types whose `FullName` is null.

_Found via automated codebase quality audit._

Start with src/Elsa/Activities/Design/Reconciliation/Clr/Services/ActivityTypeVersionResolver.cs:31, then inspect IsActivityType in ClrAssemblyScanner.cs:138-151. Reproduce the scan with a non-abstract generic RetryActivity implementing IActivity. Done when generic activity definitions cannot produce a null ActivityTypeKey, with the chosen skip or logging behavior covered by the relevant checks.

Written by the indexing model from the issue text.