Renaming a class or enum leaves dangling references inside Optional/Handle/Result wrappers and interface function signatures #222

What's wrong

TryRenameClass and TryRenameEnum (Schema/Models/Schema.Rename.cs) find references through EnumerateMemberTypes() (L168-171) and ExpandType (L173-184). That walk has two gaps:

• ExpandType recurses only into Array.ElementType. It never descends into WrapperType.ElementType (Schema/Models/Types/WrapperType.cs:19), which covers Optional<>, Handle<> and Result<>.
• EnumerateMemberTypes walks only class members. It never visits interface function return types (SchemaFunction.ReturnType) or parameter types (SchemaParameter.Type).

Failure scenario

A schema has class Foo and:

• a member typed Handle<Object(Foo)> or Optional<Object(Foo)>, and
• an interface function returning Object(Foo) or taking a Foo parameter.

TryRenameClass(Foo, "Bar") returns true, but those references still say Foo. Validate() then reports dangling references in a schema the rename promised to keep consistent. Generated code refers to a type that no longer exists, and the editor's rename-with-cascade silently breaks the schema. Enum renames fail the same way for wrapped or function-signature enum references.

Schema.Test/SchemaRenameTests.cs covers only direct and Array references, which is why this was not caught.

Suggested fix

• Make ExpandType recurse into WrapperType.ElementType, and into any other composite that holds an ElementType.
• Include every interface's function ReturnType and each parameter's Type in the enumeration, expanded the same way.
• If RepointArrayKeys uses the same walk, check it too.

Acceptance criteria

• After renaming a class or enum, Validate() reports no dangling reference for a reference nested in Optional, Handle, Result, or Array<Optional<…>>.
• The same holds for a reference in an interface function's return type or parameter type.
• SchemaRenameTests has cases for each.