Release tar/zip generation lacks reproducible member ordering and timestamps

[Widthdom]

Summary

The release workflow tar/zip generation does not enforce a stable member order or reproducible timestamps (line 205, 212). The install.sh extraction loop (line 829-832) iterates for asset in a hardcoded list and assumes extracted files will have the expected hierarchy. On rapid re-release (e.g., emergency fix), if workflow runner filesystem caching or tar streaming causes extraction to land partial trees or out-of-order members, the copy loop silently skips or overwrites. No verification step re-reads the archive member list to confirm all extracted paths match the release.yml pack step's expectations.

Where

• .github/workflows/release.yml:204-205 — cd publish && tar czf uses default member ordering
• .github/workflows/release.yml:212 — Compress-Archive does not set reproducible flags
• install.sh:808-832 — hardcoded asset list assumes extraction order is consistent

Suggested approach

1. In release.yml, add explicit tar options tar --sort=name czf to enforce alphabetic member order
2. Add tar option --mtime='2000-01-01' or use a build timestamp to ensure reproducible archive dates
3. For Windows, ensure Compress-Archive uses explicit file path ordering (or switch to 7z with consistent flags)
4. Add a post-archive validation step that lists archive member paths and compares against expected list
5. In install.sh, before the copy loop, extract and compare tar tzf output against expected filenames; fail if missing
6. Add a changelog note and update release-changelog.md to document stable archive generation requirements

[Widthdom]

Work started on branch fix-issue2040-2041-2012.