#3484 Windows: extension archives still pack directories as 0666, so registry scoring fails (No manifest.yaml found)

Summary

Now that Windows is a released platform: swamp extension push on Windows still packs extension archives with every directory entry at mode 0666 (drw-rw-rw-, no execute bit) and every file at 0666. The registry scorer can't read inside the directories, so every extension published from Windows fails scoring with:

No manifest.yaml found in tarball (searched up to 2 directory levels)

This is the problem in #3314, which was closed because Windows wasn't released yet. It still happens on the current build.

Steps to reproduce

1. On Windows, with swamp 20261014.201457.0-sha.24ef57e3, run swamp extension quality manifest.yaml (or push) for any extension. Seen today with @gluware/jira.

2. tar tvzf .swamp/cache/packages/<content-hash>/extension.tar.gz:

    drw-rw-rw- 0/0   0 2026-10-14 17:28 extension/
    drw-rw-rw- 0/0   0 2026-10-14 17:28 extension/bundles/
    -rw-rw-rw- 0/0   160048 2026-10-14 17:28 extension/bundles/jira.js
    ...

   All 16 directories are drw-rw-rw-; all 19 files are -rw-rw-rw-.

3. Push it. GET /api/v1/extensions/@gluware/jira/score returns:

    {"available":false,"reason":"failed","lastError":"No manifest.yaml found in tarball (searched up to 2 directory levels)"}

The same extension content pushed from Linux scores normally (@gluware/gluware-api 2026.10.14.2 scored 80% right away; the same code pushed from Windows as 2026.10.14.1 got no score).

Expected

Directory entries packed as 0755 and files as 0644 whatever the host OS, so a Windows publish scores like a Linux one. Normalising modes when the scorer extracts would also fix it, and would cover archives already published.

Also

Once a version fails scoring, rescoring reuses the same archive, so the only way out is to bump the version and push again.

Environment

• swamp 20261014.201457.0-sha.24ef57e3 (also seen with 20261014.203658)
• Windows 11 Pro 10.0.26300
• Private extensions in the @gluware collective