update-chrome-binaries-test-region - Claude MCP Skill

- Confirm the AWS CLI is logged into account `678892195805` by running `aws sts get-caller-identity`. If not, ask the user to log in.
- Export AWS credentials into the shell by running `eval "$(aws configure export-credentials --format env)"` (the lambda-client checks for `AWS_ACCESS_KEY_ID` and does not pick up SSO/Identity Center credentials on its own).
- From `packages/lambda`, run `bun src/admin/make-layer-public.ts --region=eu-central-1` to publish all 5 layers (fonts, chromium, emoji-apple, emoji-google, cjk) to a single test region. Flags supported by the script:
  - `--region=<region>` publishes to a single region (use this for the test phase).
  - `--skip=<region1>,<region2>` excludes regions when publishing to all (use this for the rollout phase, e.g. `--skip=me-south-1` to skip a region whose binaries are intentionally not being updated).
  - Omit both flags to publish to every region in `getRegions()`.
- The `eval` and the `bun` command must run in the same shell invocation (chain with `&&`), since the env vars do not persist across `Bash` tool calls.
- Verify the output prints a `LayerArn` and `Version` for each of the 5 layers and a final JSON dump with the published regions populated.
- **Update `packages/lambda/src/shared/hosted-layers.ts` by copying the JSON dump from the script's stdout — do NOT manually bump version numbers.** The script prints (after several blank lines) a complete `HostedLayers` object showing the exact `layerArn` and `version` AWS returned for every layer it just published. Replace the corresponding region entries in `hosted-layers.ts` with those values. For the test phase (`--region=eu-central-1`), only `eu-central-1` is updated; other regions intentionally stay on their old versions until the rollout phase.
- If you invoked the script with `--skip=<region>`, leave those skipped regions untouched in `hosted-layers.ts`.
- Update Chrome version references throughout the codebase. Ask the user for both the Chrome version (e.g. `149.0.7790.0`) and the corresponding Playwright revision (look it up in `https://github.com/microsoft/playwright/blob/main/packages/playwright-core/browsers.json` if the user does not provide it — match by `browserVersion`). Files to update:
  - `packages/renderer/src/browser/get-chrome-download-url.ts`: `TESTED_VERSION` constant, `PLAYWRIGHT_VERSION` constant, and the trailing `// <version>` comment on the `PLAYWRIGHT_VERSION` line. Also update the two hard-coded `https://remotion.media/chromium-headless-shell-amazon-linux-{arm64,x64}-<version>.zip` URLs — but **first** verify the new binaries exist by running `curl -sI` against the new URLs (and the templated `chromium-headless-shell-linux-{arm64,x64}-<version>.zip?clearcache` URLs that follow `TESTED_VERSION`). Only proceed when all return HTTP 200; otherwise ask the user to upload the missing builds to `remotion.media` first.
  - `packages/lambda/src/admin/make-layer-public.ts`: the `Chromium <version>, compiled from source.` license string passed to `PublishLayerVersionCommand`.
  - `packages/docs/docs/lambda/runtime.mdx`: prepend a new row to the "Chrome" version table for the next Remotion release. Determine the next version with `cat packages/core/package.json | grep '"version"'` and increment the patch.
  - `packages/docs/docs/miscellaneous/chrome-headless-shell.mdx`: prepend a new row to the version table, and update the example version string in the "Version tracking" section.
  - `packages/docs/docs/renderer/ensure-browser.mdx`: update both `version: '<old>'` occurrences in the example code blocks.
- Run the Docker matrix tests in `packages/dockerfiles/` (`./run.sh`) against the new Chrome binary. Each Dockerfile renders two compositions from the `BrowserTestRoot`: `browser-test` (Three.js / WebGL / codec smoke test) and `html-in-canvas` (experimental WICG `drawElementImage()` + `canvas.requestPaint()` APIs). Outputs land in `packages/dockerfiles/out/<platform>.mp4` and `packages/dockerfiles/out/<platform>-html-in-canvas.mp4`. Make sure Docker Desktop is running first.
- The Dockerfiles install the **local** workspace build of `@remotion/cli` + transitive deps (not the published version), so source changes in `@remotion/renderer` (e.g. new Chrome flags) are picked up before publishing. `run.sh` runs `pack-cli.ts` which auto-walks `@remotion/cli`'s transitive `workspace:*` deps, runs `bun pm pack` for each into `packages/dockerfiles/tarballs/`, and emits `local-cli-package.json` (lists every tarball as a direct dep AND in `overrides`, to force resolution to the local copies). Each Dockerfile then `COPY`s `tarballs/` and `local-cli-package.json` and runs `bun install` + adds `node_modules/.bin` to PATH.
- If a new composition is added to the Docker test matrix, register it in `packages/example/src/BrowserTestRoot.tsx` (so it is included in the bundle built from `src/browser-test-entry.ts`) and add a corresponding `RUN remotion render /usr/app/bundle <id> /usr/app/<filename>.mp4` line + `docker cp` extraction in `run.sh`.
- The `html-in-canvas` composition's runtime check (`packages/example/src/HtmlInCanvas/html-in-canvas.tsx`) requires both `ctx.drawElementImage` and `canvas.requestPaint`, which Chrome 149+ exposes when `--enable-features=CanvasDrawElement` is passed (already wired into `featuresToEnable()` at `packages/renderer/src/open-browser.ts:50`). If `html-in-canvas` renders fail with `"HTML in Canvas is not supported"` while `browser-test` passes, the most likely cause is a Chrome **version** mismatch — e.g. the Dockerfiles are using a published `@remotion/cli` whose `TESTED_VERSION` predates the new Chrome, so it re-downloads the older binary on top of the one `ensure.mjs` already fetched. The local-tarball install path in `pack-cli.ts` + `local-cli-package.json` is what guarantees `ensure.mjs` and the render CLI agree on the same `TESTED_VERSION`.
- Do not proceed to publishing all regions until the test region has been verified end-to-end.