[management] Code generation: update services and models

[AdyenAutomationBot]

This PR contains the automated changes for the management service.

The commit history of this PR reflects the adyen-openapi commits that have been applied.

[gemini-code-assist]

Code Review

This pull request introduces the DonationCampaignsApi service and its associated data models to support donation campaigns, alongside updates to existing payment method models, such as adding Cash App support and making several response properties optional. The review feedback highlights critical improvement opportunities: addressing potential bugs in query parameter handling where truthy checks could ignore valid falsy values (like 0 or ""), restoring type safety in InPersonDonationSettingsUpdate by replacing any | null with number | null for timeout properties, and correcting a typo (endenred instead of edenred) in the MealVoucherFRInfo description.

[gemini-code-assist]

Using the nullish coalescing operator (??) and truthy checks (if (status)) can lead to bugs when query parameters have valid falsy values (such as 0 or "".). For example, if pageSize is 0 or status is "", they will be incorrectly ignored. It is safer to explicitly check against undefined.

        if (status !== undefined || pageNumber !== undefined || pageSize !== undefined) {
            if(!requestOptions) requestOptions = {};
            if(!requestOptions.params) requestOptions.params = {};
            if(status !== undefined) requestOptions.params["status"] = status;
            if(pageNumber !== undefined) requestOptions.params["pageNumber"] = pageNumber;
            if(pageSize !== undefined) requestOptions.params["pageSize"] = pageSize;
        }

[gemini-code-assist]

Similar to the other query parameter handling, using truthy checks for parameters like searchTerm (which can be an empty string "") or pageNumber/pageSize (which can be 0) will cause them to be ignored when they are falsy but defined. Explicitly checking against undefined is much safer.

        if (searchTerm !== undefined || pageNumber !== undefined || pageSize !== undefined || goal !== undefined) {
            if(!requestOptions) requestOptions = {};
            if(!requestOptions.params) requestOptions.params = {};
            if(searchTerm !== undefined) requestOptions.params["searchTerm"] = searchTerm;
            if(pageNumber !== undefined) requestOptions.params["pageNumber"] = pageNumber;
            if(pageSize !== undefined) requestOptions.params["pageSize"] = pageSize;
            if(goal !== undefined) requestOptions.params["goal"] = goal;
        }

[gemini-code-assist]

The properties presentCardTimeoutMs and promptTimeoutMs are typed as any | null in this update model, whereas they are typed as number in the base InPersonDonationSettings model. This loses type safety. They should be typed as number | null instead.

Suggested change

	"presentCardTimeoutMs"?: any | null;
	/**
	* The time, in milliseconds, that the terminal waits for the shopper to make a selection on the donation screen. Defaults to **10000** (10 seconds). Range: 5000 to 15000.
	*/
	"promptTimeoutMs"?: any | null;
	"presentCardTimeoutMs"?: number | null;
	/**
	* The time, in milliseconds, that the terminal waits for the shopper to make a selection on the donation screen. Defaults to **10000** (10 seconds). Range: 5000 to 15000.
	*/
	"promptTimeoutMs"?: number | null;

[gemini-code-assist]

The attributeTypeMap should also be updated to use number | null instead of any | null to match the property type definition and ensure correct serialization/deserialization metadata.

        {
            "name": "presentCardTimeoutMs",
            "baseName": "presentCardTimeoutMs",
            "type": "number | null",
            "format": "int64"
        },
        {
            "name": "promptTimeoutMs",
            "baseName": "promptTimeoutMs",
            "type": "number | null",
            "format": "int64"
        },

[gemini-code-assist]

This change introduces a typo: mealVoucher_FR_endenred instead of mealVoucher_FR_edenred (Edenred is the correct spelling). Please correct this in the OpenAPI specification or the model description.

Suggested change

	* The list of additional payment methods. Allowed values: **mealVoucher_FR_endenred**, **mealVoucher_FR_groupeup**, **mealVoucher_FR_natixis**, **mealVoucher_FR_sodexo**.
	* The list of additional payment methods. Allowed values: **mealVoucher_FR_edenred**, **mealVoucher_FR_groupeup**, **mealVoucher_FR_natixis**, **mealVoucher_FR_sodexo**.