feat(aws-lambda): arm64 video function image from the handler ZIP (#6064)

* feat(aws-lambda): arm64 video function image from the handler ZIP

The image is the release handler ZIP with its x86 ffmpeg and Chrome swapped for
the native ffmpeg tree and the sha256-pinned Sparticuz arm64 Chrome pack, so the
x86 and arm64 functions run the same handler code. The image stage only copies,
so any host builds it. CI builds it and runs ffmpeg, a real Chrome render and the
Lambda runtime on an ARM runner.

* fix(aws-lambda): launch Chrome in the image smoke the way Lambda does

@sparticuz/chromium inflates its AL2023 libraries only when AWS_EXECUTION_ENV
names a Node runtime; Lambda sets it, a bare docker run does not. The workflow
also runs on @sparticuz/chromium bumps and handler ZIP layout changes, which
re-stage the image.

* fix(aws-lambda): smoke the arm64 image through its own Lambda runtime

The smoke is now a handler invoked through the image's entrypoint, whose
bootstrap sets AWS_EXECUTION_ENV the way Lambda does, so @sparticuz/chromium
takes its Lambda branch with nothing set by hand. It returns the value it saw.

* fix(aws-lambda): agree the move of the ffmpeg build workflow into the image workflow

* fix(aws-lambda): build the Chrome pack URL from the pin and hand the checked pack to tar in memory

scripts/check-no-main-deletions.mjs

@@ -1909,6 +1909,10 @@ export const ALLOWED_DELETIONS = new Map([
     "packages/engine/src/services/frameCapture-releaseInjectedVideoMedia.browser.test.ts",
     "the revert of #5795 removes releaseInjectedVideoMedia, the only code this file tested",
   ],
+  [
+    ".github/workflows/lambda-ffmpeg.yml",
+    "the ffmpeg build moves into lambda-arm64-image.yml, which also builds and smokes the image",
+  ],
 ]);
 
 export function parseBase(argv, fallback = "origin/main") {