fix: Stack overflow when transpiling type with self-referential property - #1233

The ancestor-based cycle detection only grew its set inside MapObjectType, so
a type that *is* a collection or dictionary of itself never passed through a
guarded frame: class Tree : List<Tree> and class Config : Dictionary<string,
Config> recursed until the stack overflowed. Record the current type in the
enumerable and dictionary branches as well, reporting the item or value type so
existing messages keep naming the type that holds the cycle.

Identity-based detection cannot see a recursively constructed generic such as
class Node<T> { Node<Node<T>> Child { get; set; } }, because every expansion
yields a previously unseen Type. Cap the length of a single path through the
type graph instead. A guard on the generic type definition was rejected because
it would reject legitimate nesting like List<List<string>>.

Printer-column discovery now skips properties annotated with [Ignore]. Such a
column referenced a JSON path that does not exist in the generated schema, and
walking an ignored member was the remaining way to reach the unbounded generic
expansion without the schema walk failing first.

Refs GH-1233
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The ancestor-based cycle detection only grew its set inside MapObjectType, so
a type that *is* a collection or dictionary of itself never passed through a
guarded frame: class Tree : List<Tree> and class Config : Dictionary<string,
Config> recursed until the stack overflowed. Record the current type in the
enumerable and dictionary branches as well, reporting the item or value type so
existing messages keep naming the type that holds the cycle.

Identity-based detection cannot see a recursively constructed generic such as
class Node<T> { Node<Node<T>> Child { get; set; } }, because every expansion
yields a previously unseen Type. Cap the length of a single path through the
type graph instead. A guard on the generic type definition was rejected because
it would reject legitimate nesting like List<List<string>>.

Printer-column discovery now skips properties annotated with [Ignore]. Such a
column referenced a JSON path that does not exist in the generated schema, and
walking an ignored member was the remaining way to reach the unbounded generic
expansion without the schema walk failing first.

Refs GH-1233

## Problem

The CRD transpiler walks the type graph twice — once for the schema
(`Map`/`MapObjectType`) and once for printer columns
(`MapPrinterColumns`). Both terminate via a path-scoped `HashSet<Type>`
of ancestors. Two classes of input escape that guard:

**1. The ancestor set only grows inside `MapObjectType`.** The
enumerable and dictionary branches passed `ancestors` through unchanged,
so a type that *is* a collection or dictionary of itself never passed
through a guarded frame:

```csharp
public class Tree : List<Tree>;                     // Map -> MapEnumerationType -> Map -> ...
public class Config : Dictionary<string, Config>;   // Map -> Map -> ...
public class A : List<B>;  public class B : List<A>;
```

These recursed until the process died with `Stack overflow.` — not
catchable, so neither the `catch` in `Transpile` nor the
`[PreserveUnknownFields]` fallback could turn it into a diagnostic.

**2. Cycle detection compares `Type` identity.** A recursively
constructed generic produces an endless chain of *distinct* types, so
the guard can never match:

```csharp
public class Wrapper<T> { public Wrapper<Wrapper<T>>? Inner { get; set; } }
```

In the schema walk this overflowed the stack. In the printer-column walk
— which is iterative — it was a genuine infinite loop: a measured run
sat at 2 minutes 26 seconds and 2.8 GB RSS, still growing, and had to be
killed. That path was reachable even when the property was annotated
`[Ignore]`, because printer-column discovery did not evaluate
`[Ignore]`.

## Changes

- **Record the current type in the enumerable and dictionary branches**
before descending into the item/value type. The item or value type is
reported rather than the collection, so the message for the
already-covered case `class A { List<A> X; }` keeps naming `A`.
- **Cap the length of a single path through the type graph**
(`MaxTypeGraphDepth = 100`) in both walks. A guard on the generic type
definition was considered and rejected: it would reject legitimate
nesting such as `List<List<string>>`. The new exception is a
`CircularTypeReferenceException`, so existing catch clauses and the
`[PreserveUnknownFields]` degradation keep working.
- **Skip `[Ignore]` properties during printer-column discovery.** A
column below an ignored property referenced a JSON path that does not
exist in the generated schema.

## Verification

Each case run through `Transpile` before and after:

| Input | Before | After |
|---|---|---|
| `class Node { List<Node> Children; }` (control) |
`TranspilationFailedException … circular … 'Node'` | unchanged |
| `class Tree : List<Tree>` | `Stack overflow.` | `… circular … 'Tree'`
|
| `class Config : Dictionary<string, Config>` | `Stack overflow.` | `…
circular … 'Config'` |
| `Wrapper<Wrapper<T>>`, schema walk | `Stack overflow.` (1470 frames) |
`… exceeds the maximum nesting depth of 100 …` |
| `Wrapper<Wrapper<T>>` behind `[Ignore]` | infinite loop, 2m26s / 2.8
GB RSS | transpiles immediately |

`KubeOps.Transpiler.Test` 241/241, `KubeOps.Generator.Test` 61/61,
`KubeOps.Cli.Test` 31/31 (2 skipped). `dotnet build -c Release` with no
new warnings, `dotnet format --verify-no-changes` clean. Seven new tests
in `Crds.Mlc.CircularReference.Test.cs`, including a negative test
asserting the depth limit does not fire on `List<List<string>>`.

## Behaviour changes

- Type graphs that previously crashed or hung now fail with a
descriptive `TranspilationFailedException` during generation.
- An `[AdditionalPrinterColumn]` below an `[Ignore]` property is no
longer emitted. It previously produced a column whose `jsonPath` pointed
at a field absent from the schema.
- `[PreserveUnknownFields]` still opts a subtree out of the schema only,
not out of printer-column discovery. That inconsistency is left
untouched here.

## Relation to #1233

The `[Ignore]` filter in `MapPrinterColumns` is the same change as #1233
and will conflict textually. The stack overflow described in that PR's
title is the case `class Tree { List<Tree> Children; }`, which is
already handled by the cycle guards from #1141/#1201; what remains
reachable through an ignored member is the infinite loop measured above.

Docs updated in `docs/docs/operator/building-blocks/entities.mdx`.