[AryaKesharwani]

What

hyperframes render now rejects an unusable --video-bitrate up front, with a usage error and exit code 2, instead of failing inside ffmpeg after capture.

Why

--video-bitrate was only checked for being non-empty, and the raw string went to ffmpeg's -b:v. A typo like abc or 10x ran the whole capture, crashed the streaming encoder, retried on a fresh screenshot session, and only then failed with Render failed. 0 was accepted and silently rendered. --max-bitrate already rejects these values before capture with ✗ Invalid bitrate cap, so the two bitrate flags behaved differently.

Real CLI in Docker (node 22, Chromium, ffmpeg), rendering a short demo project:

--video-bitrate	main	this PR
abc	encoder dies mid-render, retries, ✗ Render failed, exit 1 after 18s	✗ Invalid video-bitrate / Got "abc". Must be a positive bitrate such as "10M" or "8000k"., exit 2 in under 1s
10x	same, exit 1 after 16s	same usage error, exit 2
0	renders, exit 0	usage error, exit 2
8M	renders	renders (unchanged)

Related work

No existing issue. This is a tiny self-contained correction. #5549 added videoBitrate to the studio render route, and #6444 added --max-bitrate, whose parser this reuses.

How

createRenderPlan validates --video-bitrate with the engine's appendRateCapArgs, the same parser parseDeliveryFlags uses for --max-bitrate. It accepts the same <number>[k|M|G] forms and rejects zero.

Test plan

• Unit tests added/updated: rejects --video-bitrate %s before capture for abc, 10x, 0 and 0M in plan.test.ts. The new cases fail on main, and plan.test.ts passes 47/47 with the change. tsc, oxlint and oxfmt are clean.
• Manual testing performed: the CLI runs in the table above, on main and on this branch.
• Documentation updated (if applicable): not needed, since the flag's documented forms are unchanged.
• Comments follow CONTRIBUTING.md "Comments".