Investigate catching missing assets earlier in PR checks

Description

This always happens only after merging, when building strict for container registry, and is not caught beforehand:

3.171     cache_name = self.clean_name(self.hashed_name(name))
3.171                                  ~~~~~~~~~~~~~~~~^^^^^^
3.171   File "/venv/lib/python3.13/site-packages/django/contrib/staticfiles/storage.py", line 144, in hashed_name
3.171     raise ValueError(
3.171         "The file '%s' could not be found with %r." % (filename, self)
3.171     )
3.171 ValueError: The file 'img/firefox/new/desktop/android.png' could not be found with <django.contrib.staticfiles.storage.ManifestStaticFilesStorage object at …>.
------
failed to solve: process "/bin/sh -c honcho run --env docker/envfiles/prod.env docker/bin/build_staticfiles.sh" did not complete successfully: exit code: 1
make: *** [Makefile:149: build-ci] Error 1

But it can also be not importing a lib SASS with path var configured, ending up looking for assets in a wrong (lib default) location etc.

The PR CI is not catching these (even though we are building things for test incl. assets IIRC, in make build-ci, which should be the same strict setup, correct? It's just the failure point of this is actually in release stage IIUC), and locally this also tends to be a little tough to catch, as something like make build-prod is needed to make sure everything's in.

Wondering if there's an inexpensive way to somehow run the build_staticfiles.sh just for test purposes when we have the assets or assets-tmp already, in a way that would not burn through many resources or add extra minutes to each run.

Success Criteria

• Having visibility into strict builds succeeding before merging to main
• Either by having the strict build run in the PR CI already, or by adding a linter to just iterate over the files checking they are not missing for the PR diff?

Start by tracing the PR CI and release stages around Makefile targets build-ci and build-prod, then inspect docker/bin/build_staticfiles.sh and the existing assets or assets-tmp outputs. Compare the strict production build with the test build and determine which check can expose missing assets before merging; done means strict-build failures are visible in PR checks without unnecessary extra resources.