Hardening supply chain security against recent npm attacks

Needless to mention there's been a wave of npm supply chain attacks recently (Shai-Hulud, the axios hijack, TanStack compromise, etc.), often through install scripts. Given how many packages we depend on, it would be good to harden the setup of pgAdmin and vist the idea once.

A few suggestions:

1. Block install scripts from running automatically

By default, any package can run arbitrary code during install via preinstall/postinstall scripts, almost always without the knowledge of maintainers or ddevloper. This is actually how most of these recent attacks execute their payload. Setting enableScripts: false in .yarnrc.yml blocks this by default, with an explicit allowlist for packages that genuinely need it (like sharp, which downloads a native binary on install).

2. Enforce immutable lockfile checks in CI

yarn.lock can be tampered with or silently modified during CI builds to pull in mismatched hashes or unreviewed dependencies. Not to say the maintainers here aren't careful, but this kind of change is easy to miss in a normal PR review, since nobody reads a thousand-line lockfile diff line by line. Switching to yarn install --immutable in our GitHub Actions workflows and setting checksumBehavior: throw in .yarnrc.yml would catch any lockfile drift or hash mismatch automatically before a build even runs. This benefits the project by guaranteeing 100% reproducible builds and failing early if a lockfile is out of sync or compromised, ensuring unverified code is never bundled into public releases.

3. Pin @fortawesome/fontawesome-free to an explicit version

@fortawesome/fontawesome-free is currently the only package in web/package.json set to "latest" instead of a version number. Not sure if there was a specific reason for leaving it open-ended, but it risks pulling in surprise breaking changes whenever dependencies are refreshed. Pinning it to ^7.2.0 (which is what's already in the lockfile) would bring it in line with the rest of the repo and allow Dependabot to track and open PRs for future updates properly. That said, this is just a recommendation; you can disregard this if you only assume there isn't already a substantial reason to keep it on latest.

4. Bump the minimum release age gate

Yarn 4.15.0 (which we are already pinned to) defaults npmMinimalAgeGate to 1 day, delaying the install of just-published package versions. Worth bumping this to 3 days, since most compromised packages take a bit longer than 24 hours to get caught and pulled. Renovate also defaults to a 3-day cooldown, so it's not an unusual number.

Pls share your insights @dpage @asheshv.

Start by reviewing .yarnrc.yml, web/package.json, yarn.lock, and the GitHub Actions workflows to understand the current dependency and install configuration. Check how the existing Yarn 4.15.0 setup handles scripts, checksums, lockfile immutability, Font Awesome, and package age. Done means the agreed hardening changes are applied consistently and CI verifies the resulting dependency configuration.