* build(aws-lambda): pinned native ffmpeg build for an arm64 Lambda image
One recipe, run per architecture on the Lambda Node 22 base it ships on. Codec
libraries link statically; glibc and GnuTLS stay dynamic, with the two libraries
the bare base lacks bundled beside the binaries. A check stage on the bare base
proves every encoder, decoder, filter and protocol the engine calls, and the
artifact cannot be produced without it. CI builds it on two ARM runners and
requires byte-identical tarballs.
* fix(aws-lambda): link GnuTLS dynamically in the arm64 ffmpeg build
With --static pkg-config flags, gnutls.pc names a libgmp.a from its own RPM build
tree and configure rejected GnuTLS. The codec libraries exist only as static
archives, so they still link statically. The recipe moves to image/, which will
also hold the video function image stage.
* fix(aws-lambda): build x265 for arm64 with the base image compiler
x265 builds its SVE2 kernels with -march=armv9-a, which gcc 11 rejects. Turn
them off, and stop a failed x265 build from reaching ffmpeg configure as a
misleading "x265 not found".
* fix(aws-lambda): pin x264 to the revision the x86 ffmpeg uses
The x86 ffmpeg-static 7.0.2 encodes with x264 r3191 (4613ac3); match it.
* fix(aws-lambda): 10-bit x265 in the arm64 ffmpeg, checked by output format
x265 now builds the 10-bit library and links it into the 8-bit one, so HDR
renders get yuv420p10le instead of a silent 8-bit fallback. The check asserts
the encoded pixel format rather than a successful command, and its ffprobe calls
terminate options with -- like every other caller.
