GenerateMock silently produces no type and no diagnostic for large interfaces

[thomhurst]

When [assembly: TUnit.Mocks.GenerateMock(typeof(T))] is applied to a large interface, the source generator produces no output and emits no diagnostic. The attribute line itself compiles (proving the type is accessible), but the generated TMockable type simply does not exist, causing CS0246 at every usage site with no indication of what went wrong.

To reproduce

1. Add GenerateMock for a large SDK-generated interface — e.g. one with 100+ method overloads
2. The attribute compiles without error
3. Reference TMockable anywhere in the project
4. Build → CS0246: The type or namespace name 'TMockable' could not be found

Switching to a smaller interface (e.g. one with ~30 methods) works correctly with identical setup.

Expected behavior

Either the mock is generated, or a diagnostic is emitted explaining why generation failed:

▎ TUnit.Mocks: failed to generate mock for 'T'. [reason]

Actual behavior

No generated type. No warning. No error from the generator. Only a CS0246 at the call site with no pointer to the root cause.

Additional context

The failure appears to be interface-size-dependent. The generator likely hits an internal limit or encounters an unhandled exception on a specific method signature and swallows it. A diagnostic on failure would make this immediately debuggable.

[claude]

Not a duplicate of an existing open issue, but part of a recurring pattern in TUnit.Mocks worth flagging for whoever picks this up:

• [TUnit.Mocks] Two mocked types whose sanitized names collide silently generate nothing (e.g. A_B.IFoo and A.B.IFoo) #6505 and [TUnit.Mocks] Generated mock wrapper type names collide across namespaces (e.g. two different ICluster interfaces) - one silently loses its members #6494 are also cases of the generator silently producing no/partial output with zero diagnostics (hint-name and short-name collisions respectively) — different root cause than interface size, but the same class of bug: the generator has failure paths that produce no AddSource output and no Diagnostic.
• fix: source generator diagnostics use Location.None and lose exception info #4865 covers the same underlying gap (Location.None, swallowed exceptions) but for TUnit.Core.SourceGenerator, not TUnit.Mocks — the mocks generator likely needs the equivalent treatment: wrap generation in a top-level try/catch that reports a diagnostic with real location/exception info instead of failing silently.

Given the number of independent silent-failure reports against TUnit.Mocks, it may be worth adding a generic safety net (catch-all diagnostic on unhandled exception during mock generation) rather than only fixing size-specific limits, so future failure modes surface instead of silently producing CS0246 at the call site.