Fix TS exactOptionalPropertyTypes compatibility for generated types

[huntie]

Summary:
NOTE: Patches over a flow-api-translator bug, which I'll fix upstream later. We need to pick this to 0.87-stable to resolve user integration issues.

Context

TypeScript's exactOptionalPropertyTypes flag (strict mode) creates a distinction between foo?: T and foo?: T | undefined.

// Flow's semantics

interface Props {
  onRefresh?: () => void;
}
const a: Props = { onRefresh: undefined }; // ✅ ok

// TypeScript with exactOptionalPropertyTypes: true (i.e. strict mode)

interface Props {
  onRefresh?: () => void;
}
const a: Props = { onRefresh: undefined }; // ❌ error

interface PropsFixed {
  onRefresh?: (() => void) | undefined;
}
const b: PropsFixed = { onRefresh: undefined }; // ✅ ok

With this added strictness in TypeScript, our generated types via flow-api-translator could create downstream type incompatibility in apps.

This diff

Patches the above issue in React Native's Flow → TS types_generated/ pipeline. We transform all instances to the wider foo?: T | undefined format, for maximum compatibility.

Notes

foo?: T [| undefined] remains stripped in the API snapshot (existing transform with the aim of a concise format). There is a net, nonfunctional snapshot diff around function members, which (as a positive result) are re-ordered.

Changelog:
[General][Fixed] - Strict TypeScript API: Optional property types are now widened to explicitly include | undefined for exactOptionalPropertyTypes compatibility

Differential Revision: D113030161

[meta-codesync]

@huntie has exported this pull request. If you are a Meta employee, you can view the originating Diff in D113030161.

[github-actions]

Warning

JavaScript API change detected

This PR commits an update to ReactNativeApi.d.ts, indicating a change to React Native's public JavaScript API.

• Please include a clear changelog message.
• This change will be subject to additional review.

This change was flagged as: POTENTIALLY_BREAKING