getSignupRequests declares rows under 'data' where the provider serves 'signupData', and types them as [key: string]: any

[willcalcote]

Summary

getSignupRequests declares its rows under data, but the provider - Layer5 Cloud (meshery-cloud) - has only ever served them under signupData. The rows are also generated untyped, so neither half of the contract helps a consumer.

The disagreement

Generated (dist/cloudApi.d.ts, @meshery/schemas v1.3.44):

type GetSignupRequestsApiResponse = {
    page?: number;
    pageSize?: number;
    totalCount?: number;
    /** Signup requests returned on the current page. */
    data?: {
        [key: string]: any;
    }[];
};

Provider (server/models/users.go:306-311 in layer5io/meshery-cloud):

type SignupRequestsPage struct {
	SignupData []*SignupData `json:"signupData"`
	Page       int           `json:"page"`
	PageSize   int           `json:"pageSize"`
	TotalCount int           `json:"totalCount"`
}

The three scalars agree. The rows key does not: data vs signupData.

Why it matters

A consumer that trusts the generated type reads response.data and gets undefined. In meshery-cloud that is exactly what happened - the signup-requests admin table rendered no rows at all until it was repointed at signupData (layer5io/meshery-cloud#5985).

Nothing catches this. The key is not a compile error because the consumer is reading a declared optional property, and the element type { [key: string]: any } means every column accessor on those rows is unchecked too - so a row-level field rename is equally silent. The second half is worth fixing alongside the first: SignupData is a real, fully-typed struct on the provider side (firstName, lastName, email, organization, occupation, role, formType, status, taskId, taskLink, createdAt, updatedAt), so the rows can be declared rather than left open.

Asks

1. Rename the envelope property to signupData to match the wire the provider actually serves.
2. Declare the element type instead of { [key: string]: any }.

Reported from layer5io/meshery-cloud#5985, which works around it locally and cites this issue. Per that repo's contract the provider's handler is the arbiter where meshery-cloud is the producer, so the spec is what should move.