Exclude thirdparty/licenses from the docker image source checksums

[Grantim]

Rescoped per review to the checksum-input change only; the rebuild/selection mechanism is #6436's registry check, with which this composes under either merge order.

Problem: docker_image_source_checksum.sh hashed thirdparty/licenses/**, so licenses-only commits (#6429, #6422, #6434) moved every Linux image's expected source-checksum-* tag on commits that build no new image. Under the old paths-filter world that meant tags that were never pushed (manifest unknown for consumers pinning them); under #6436 it would mean a pointless full image-rebuild cycle and tag churn on every license-text edit.

Fix: exclude thirdparty/licenses/** from the hashed set -- license texts ship in packages and are not image inputs. The script comment now states the invariant: hash only paths that affect image content.

Transition note (applies regardless of mechanism): redefining the hash invalidates all previously pushed source-checksum-* tags. This PR's earlier full-matrix run already minted and pushed new-definition tags for current master content (e.g. emscripten source-checksum-aa94f48bb1837b1d); consumers pinned to older commits compute old-definition tags that will never exist, and unblock only by moving their pin past this merge.

Test plan

• bash -n; checksum computed for all six distro cases (ubuntu22/24, emscripten x3, rockylinux8-vcpkg).
• With the exclusion, recomputing across the licenses-era commits yields identical tags -- license edits no longer move them.

[Fedr]

The licenses exclusion and the self-bootstrapping trick of adding the checksum script to the filters both look right. A few findings:

1. The alignment is incomplete. After this PR, these paths are still hashed by docker_image_source_checksum.sh but absent from the linux-changes filter, so any of them changing reproduces today's incident (tag moves, no rebuild, manifest unknown):

• scripts/thirdparty/** — the whole directory of third-party build scripts and patches, the most frequently-changed checksum input of all
• scripts/ask_emscripten_mode.src
• scripts/cmake_install.sh (the emscripten-only extra)
• scripts/install_thirdparty.sh
• scripts/install_apt_cuda.sh
• requirements/python/requirements.txt
• scripts/mrbind-pybind11/python_versions.txt
• scripts/mrbind-pybind11/install_all_python_versions_ubuntu_pkgs.sh

If we keep the alignment approach, these should be added to the filter in the same PR — otherwise the new sync-invariant comment is false on day one. Inverse (harmless) direction: requirements/distribution_python.txt is in the filter but not hashed, so it only over-triggers a reuse/repoint run.

2. Overlap with #6436. That PR solves the same incident by deleting the linux filters and gating prepare-images on a registry check instead (conventional tag resolved to leaf manifest digests vs the source-checksum tag), which also covers the cases alignment can't: a rebuild that fired but failed to push (canceled run, registry error) leaves the tag absent forever, since the next run's filter sees no relevant diff. The two PRs conflict in config.yml and define tags differently, so we should pick a direction before merging either. They compose well: the thirdparty/licenses/** exclusion here is valuable under either architecture, while the filter edits are superseded if #6436 lands.

3. Transition note. Redefining the checksum invalidates every existing source-checksum-* tag; this PR's run mints new-definition tags for current content, but consumers pinned to older commits still compute old-definition tags (e.g. f64b0a7a…), which never existed and never will. They unblock only by moving their pin past this merge — worth stating explicitly in the body.

4. Stale caveat. fix-docker_multiple_mirrors merged this afternoon (#6428), so the arm64 apt-mirror warning in the body is moot — the merge-ref builds already include the mirror fixes.

[Fedr]

The rescope addresses points 1 and 2 cleanly — no config.yml conflict, no overstated invariant, and the comment now states the right principle. One remaining issue: merge ordering.

Dropping the script-in-filter hunk removed the part that minted the redefined tags. As rescoped, the PR changes every source-checksum-* value while guaranteeing none of the new tags get built:

• This run confirms it: scripts/devops/ is not a filter path, so every prepare-image job was skipped.
• The new-definition emscripten tag from the first commit's run (97778d8e0d94d3f0) is absent on Docker Hub — that run was superseded before pushing, so no new-definition tags exist at all.
• The master run after merging behaves the same: checksums move, nothing rebuilds. The gap only closes when a later PR happens to touch a filter path — i.e. the PR reintroduces the incident class it fixes, triggered by itself.

Two clean resolutions:

1. Merge CI: single content-addressed criterion for Docker image selection and rebuilds #6436 first, then this (preferred): its registry-digest gate sees the new-definition tags as absent on the first master run after this lands and rebuilds automatically — the redefinition self-heals with no manual step.
2. If this must land first: restore the script-in-filter addition from the original commit (or dispatch an image build right after merge).

Context on urgency: f64b0a7a… has been manually retagged from the content-identical c762f88e…, so current downstream pins pull fine either way — this is about not leaving a time bomb, not about an active breakage.

[Fedr]

Closing as superseded by #6436, which solves the same incident at the root: the paths-filters are gone entirely — prepare-config now syncs every conventional tag to its source-checksum-* tag directly against the registry (unconditional imagetools create), so the filter/checksum alignment this PR maintained by hand no longer exists as a concept. The thirdparty/licenses/** checksum exclusion from here is still worth having as an optimization (license edits currently cost a no-op-content rebuild); feel free to reopen it as that single hunk on top of #6436 once it merges.