At the same time, the AMP project is actively working to move the origin (control/host) of the AMP Javascript to the publisher's own domain, as well as allow a version served on an origin owned by the OpenJS Foundation, rather than Google.
On publisher origin, the plan-of-record does not involve any validation of the contents of the AMP javascript files. When an AMP Cache (eg: Google) crawls one of these AMP documents, the same is true - the contents of the javascript files will not be relevant to the decision of whether or not the document is considered valid AMP. The files will likely not even be crawled by the Cache.
However, when the AMP Cache serves one of these files, it will rewrite them to the latest* version for serving to users. This is necessary since the javascript runs in a somewhat privileged context in search results.
https://github.com/ampproject/amphtml/issues/25873
* There is also a mechanism for publishers to opt-in documents to a "Long-Term Stable" release, rather than the latest evergreen version: https://amp.dev/documentation/guides-and-tutorials/learn/spe...
Lastly, and there is still some discussion around this, it is likely that Signed Exchanges may be able to load the publisher's own version of the javascript in the future, even in search results. This is because the execution context of the javascript is different for Signed Exchanges.