codegen: resync gen/ from EF f4301d8c

[heygen-rui-bot]

Auto-generated PR: a production deploy shipped an updated OpenAPI spec. This PR contains the CLI command definitions regenerated from the now-live prod spec in gen/.

What changed

No change to the command surface; this resync updates descriptions or request/response schemas only.
Compared against heygen-cli main at b6e6b0265ae37459e7019ff5d83f0e35c1e87fce.

If CI fails (e.g. missing examples), fix the issue and push to this branch.

Source commit: f4301d8c52ab805ccbd0753530345eb9295070cd
Triggered by: https://github.com/heygen-com/experiment-framework/commit/f4301d8c52ab805ccbd0753530345eb9295070cd

[somanshreddy]

Reviewed. Content is correct and minimal, but the PR body is wrong in a way that matters for the release notes.

What actually changed

Semantic diff of both files: the only change is "deprecated": true added at five schema locations. No description churn, no schema restructuring, nothing else. This is API-576 propagating through, and it is exactly what was expected.

The body says "No change to the command surface" — that is not right

Three commands lose a flag from --help:

command	flag
heygen lipsync create	--enable-caption
heygen video-translate create	--enable-caption
heygen video-translate proofreads generate	--captions

Verified by building this branch: all three are gone from --help. They still work and still send their value, and using one now prints a stderr warning, but a user reading --help will no longer find them.

The bot's "command surface" heuristic only tracks public commands added or removed, so it is blind to flag-level changes. Not a bug in this PR, but it means the body cannot be trusted as the summary of user-visible impact.

Why five schema markers but three hidden flags

The two batch commands (lipsync batches create, video-translate batches create) carry the field nested inside an array of payloads, so codegen never emitted a flag for it — there is nothing to hide. They do surface the marker via --request-schema at /properties/lipsyncs/items/properties/enable_caption, which is the only place a -d composer would see it. Correct on both counts.

Behavior verified end to end

• --enable-caption absent from --help on all three.
• Supplying it through -d still warns: {"warning":{"message":"--enable-caption: it is deprecated..."}} on stderr, with stdout still clean JSON and the value still sent.
• --request-schema reports the marker on the batch commands.

Two notes

goreleaser-check was red on Unexpected HTTP response: 503, an infrastructure flake unrelated to the diff. Re-ran it; 8/8 green now.

Release notes: whatever ships next needs a Deprecated entry naming these three flags. Nothing else will surface it — the changelog files resyncs under Internal, and the body says there is no surface change.

[github-actions]

Command surface: 3 existing command(s) changed

Changed — these already existed, so a change can break existing calls.

heygen lipsync create

+ 			Deprecated: true,

heygen video-translate create

+ 			Deprecated: true,

heygen video-translate proofreads generate

+ 			Deprecated: true,

_{Reference only, never blocking. See RELEASE.md "Checking for Regressions" for how to read this.}

[somanshreddy]

Content verified: only deprecated: true markers, nothing else. Three commands lose a flag from --help (lipsync create, video-translate create, video-translate proofreads generate); behavior verified end to end on this branch. Needs a Deprecated entry in the next release notes.