Extend cache-control's max-age for `main.HASH.js`

It looks like we use URL-based caching for the main javascript file, based on the fact that the name contains a hash and the HTTP header contains a set max-age:

C:\Users\Pieter>curl  -I https://www.openml.org/static/js/main.27ea998a.js
HTTP/1.1 200 OK
Date: Mon, 22 May 2023 20:58:21 GMT
Server: gunicorn/20.0.4
Content-Length: 2130393
Content-Type: application/javascript; charset=utf-8
Last-Modified: Wed, 03 May 2023 17:30:58 GMT
Cache-Control: public, max-age=43200
Expires: Tue, 23 May 2023 08:58:21 GMT
ETag: "1683135058.0947442-2130393-3808763291"
Accept-Ranges: bytes
Access-Control-Allow-Origin: *

Why then is the max-age only set to 12 hours? It is my understanding that with this setup, invalidation should happen by updating the HTML page to reference a different javascript file. The max-age can then be set to something much larger (a month or year), so that conceivably there is never a cache validation round trip explicitly for the javascript file.
Updating the max-age will result in viewer round trips which lightens server load and gives the user a faster experience.

Start by tracing how the generated main.HASH.js asset is served and where its Cache-Control header is configured. Use the curl request shown in the issue to verify the current header, then confirm that the asset uses a substantially longer max-age while the HTML references the hashed filename.