fix(goctl): resolve multi-level struct embedding in TypeScript generation

[kevwan]

Description

Fixes #5402

When using multi-level nesting in type definitions (e.g., AgeStruct embeds NameStruct which embeds IdStruct), the TypeScript code generation was losing fields from the deepest embedded structs.

Problem

Given the following API definition:

type (
    IdStruct {
        Id int64 `json:"id"`
    }
    NameStruct {
        IdStruct
        Name string `json:"name"`
    }
    AgeStruct {
        NameStruct
        Age int `json:"age"`
    }
)

The generated TypeScript was incorrectly missing the id field:

export interface AgeStruct {
    name: string
    age: number
}

Root Cause

The type resolution in fillTypes() did a single pass through types, looking up embedded struct references from the original unresolved type list. This meant multi-level embeddings couldn't resolve properly because nested embedded types were not yet fully resolved when they were referenced.

Solution

Implemented iterative type resolution that:

1. Resolves types in multiple passes until no changes occur
2. Looks up types from both the currently-resolved types (within the iteration) and the original list
3. Prioritizes recently-resolved types to handle multi-level embeddings correctly

Result

After the fix, the generated TypeScript correctly includes all fields:

export interface AgeStruct {
    id: number      // ✅ Now included (from IdStruct)
    name: string    // ✅ From NameStruct
    age: number     // ✅ Direct field
}

Testing

• Verified fix with the reported test case
• Existing parser tests continue to pass

This ensures all embedded struct fields are properly flattened in the generated TypeScript interfaces.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[Copilot]

Pull request overview

This PR updates the API parser’s type-resolution step so that embedded structs are resolved across multiple levels, preventing TypeScript generation from losing fields coming from deeply embedded structs (as reported in #5402).

Changes:

• Reworks Analyzer.fillTypes() to iteratively resolve embedded spec.DefineStruct references until resolution stabilizes.
• Adds a helper findTypeInList() to prefer types already resolved earlier in the same iteration.

[Copilot]

The loop break condition can stop iterations too early: changed is only set when the embedded struct’s member count changes. For deeper embedding chains (e.g., A embeds B embeds C embeds D), B/C can become “more resolved” (inner embedded members replaced) without changing len(Members), so changed stays false and earlier structs may never pick up the newly-resolved versions. Consider setting changed when the resolved type differs from the current member.Type (e.g., !reflect.DeepEqual(member.Type, tp)), or alternatively always run up to maxIterations and break only when no member.Type replacements occur in an iteration.

[Copilot]

This change is a regression fix for multi-level struct embedding resolution, but there isn’t an automated test covering it in this package. Adding a parser/analyzer test that asserts embedded fields are fully flattened (including a chain deeper than 2 levels and with types defined out-of-order) would prevent future regressions.