Rn/prebuild mdx transforms

[RubenSandwich]

• 🎟️ Ticket - run MDX transforms through a pre-build binary

Description

Speeds up prebuild by running a prebuilt prebuild binary compiled with bun.

This did require a few changes:

1. Adding a run-prebuild.mjs that runs the arch appropriate prebuild binary
2. When creating the prebuild binary, we gzip it or else we go past the 100mb github file size limit
3. Creating a check-prebuild-binaries.yml GHA file that if any files used by prebuild are changed makes sure the binary is rebuilt

Other things are where not strictly necessary but where done to improve the code/make writing the check-prebuild-binaries.yml GHA easier:

1. Putting most prebuild files in a /prebuild folder
2. Updating to use modern node std lib style imports
   1. Instead of import fs from 'fs'
   2. Using import fs from 'node:fs'
3. Using Node import path resolution so we can use alias's in .mjs files
4. Moved productConfig.mjs to the root folder as it's used by both /app and /scripts

Benchmarks

BEFORE (on main):

hyperfine -w 1 -r 3 "npm run prebuild"
  Time (mean ± σ):     139.261 s ±  1.259 s    [User: 127.043 s, System: 31.478 s]
  Range (min … max):   138.336 s … 140.695 s    3 runs

AFTER (on this branch):

hyperfine -w 1 -r 3 "npm run prebuild"
Benchmark 1: npm run prebuild
  Time (mean ± σ):     69.104 s ±  0.623 s    [User: 58.733 s, System: 12.838 s]
  Range (min … max):   68.478 s … 69.725 s    3 runs

Change in execution time: 69.104s / 139.261s = 0.4962
So with these changes prebuild is ~0.50% faster and saves ~1 min 10s per run.

Testing

1. test local dev env
2. test docker dev env
3. poke around on the preview to make sure that the website loads correctly

[github-actions]

Vercel Previews Deployed

Name	Status	Preview	Updated (UTC)
Dev Portal	✅ Ready (Inspect)	Visit Preview	Fri Sep 5 02:46:31 UTC 2025
Unified Docs API	✅ Ready (Inspect)	Visit Preview	Fri Sep 5 02:40:54 UTC 2025

[RubenSandwich]

These really should not be needed, but during next.js build them seem to ignore Node import path aliases... 😢

[RubenSandwich]

Yup we delete the old binary and unzip a new binary each time. It's super duper quick and it means that we don't have to worry about folks having old binaries running. Which is a big win.

[andys-hashi]

Were the path name changes necessary because of a change for this update? If not, they are out of scope for this PR and should have been a separate PR.

[LeahMarieBush]

LGTM! Ran this all locally and through docker and it sped up the build time quite a bit for me. I think it would be a good idea for someone with a windows computer to test this just to be sure it works for other operating systems.

[andys-hashi]

@RubenSandwich Please benchmark the time differences locally and in deployments before & after. We are trying to track this closely as new products are added and for improvements to the process.