fix(download-libs): rebuild against refreshed artifacts instead of reusing stale objects

[msluszniak]

Description

Two fixes to download-libs.js that let a native artifacts upgrade actually reach a machine that has built before.

Upgrading to a newer artifacts release could leave a build with new libraries but stale object files, surfacing as an undefined symbol far from the cause:

ld.lld: error: undefined symbol: executorch::extension::make_tensor_ptr(
    std::vector<int>, void*, std::vector<unsigned char>, std::vector<int>,
    ScalarType, TensorShapeDynamism, std::function<void (void*)>)
>>> referenced by tensor_ptr.h:91
>>> neural_phonemizer.cpp.o in archive phonemis/libphonemis.a

make_tensor_ptr gained a trailing Device parameter in ExecuTorch 1.4.1, so an object compiled before the upgrade kept referencing the old 7 argument symbol that the new libexecutorch.so no longer exports. Phonemis was incidental, it just happens to call the changed API.

1. extract() passed tar -xzf, which keeps the mtime recorded in the archive. Extracted headers therefore carried the timestamp of the release cut, so newer headers could look older than existing objects. Ninja compared those mtimes, treated the objects as up to date, and never recompiled them. -m stamps files with the extraction time instead.

2. isCacheValid() compared the cached tarball against the cached checksum, so a stale cache validated itself. The cache directory is keyed only on the libs version, so a release re-cut at the same version was never picked up: every artifact reported a cache hit while a fresh clone got the new files. It now fetches the checksum from the release, falling back to the cached copy when unreachable so a populated cache still builds offline.

Introduces a breaking change?

• Yes
• No

Type of change

• Bug fix (change which fixes an issue)
• New feature (change which adds functionality)
• Documentation update (improves or adds clarity to existing documentation)
• Other (chores, tests, code style improvements etc.)

Tested on

• iOS
• Android

Testing instructions

With a cache already populated from an earlier release:

1. node scripts/download-libs.js and confirm the artifacts whose checksum changed report a cache miss and re-download, rather than Cache hit, skipping download.
2. ls -la third-party/include/executorch/extension/tensor/tensor_ptr.h and confirm the mtime is the extraction time, not the release date.
3. Build the Android app without wiping .cxx and confirm objects depending on changed headers are recompiled and the link succeeds.

Verified against the live v0.10.0-libs release: a warm cache holding the previous tarball validated as a hit under the old check and correctly misses under the new one. The mtime behaviour was reproduced in a minimal CMake and Ninja project, where a header with changed content but an older mtime produced ninja: no work to do.

Related issues

Checklist

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have updated the documentation accordingly
• My changes generate no new warnings

Additional notes

The cache directory is still keyed only on nativeLibsVersion, so RNET_BASE_URL overrides pointing at a different release at the same version share a cache directory. Fetching the remote checksum makes that safe now, since the contents are compared rather than assumed, but keying the cache on the resolved base URL would be a further improvement.