Extension release checks: per-SDK tags at the built commit, sdkDigest, pinned builder, PR warnings

[amaechiabuah]

Ticket: DUPLOAI-3667

Heads up: this changes .env.example. BUILDER_TAG=latest is now commented out, because the default builder image is pinned by digest. A .env that still sets BUILDER_TAG=latest keeps building with :latest, so nothing breaks for existing users.

What

These are general release checks for extension repos. Every repo gets them at its next devkit upgrade. Checks on a PR only warn. Only the release job refuses a release that cannot ship.

• Release at the built commit, one release per SDK build. scripts/release-extensions.sh replaces the inline publish step in release.yml. It tags each release [name]-v[version]-sdk-[sdkVersion] with --target "$GITHUB_SHA". It reads sdkVersion from the built bundle.
• Fail rather than skip green. The job fails when an extension's content changed at a version that already has a release. Releases under the old [name]-v[version] tag count too. An unchanged version gets its missing per-SDK build published.
• Immutable releases. A step after each release reads its immutable flag and warns when the release landed mutable.
• sdkDigest. build-extension.sh stamps sdkDigest beside sdkVersion in the bundle manifest. It is the sha256 of the SDK feed the bundle compiled against, and scripts/_sdk_digest.sh defines it. The digest is computed from a fresh extraction of the SDK bundle, since backend/sdk-packages/ accumulates packages from earlier builds.
• Pinned builder. _builder.sh and docker-compose.yml default to duplo-extension-builder@sha256:8185e6a7…, which is the current :latest. BUILDER_TAG and BUILDER_IMAGE still override it. builder-image.yml prints the new digest after each publish, so a toolchain move is a reviewed one-line PR.
• PR warnings. scripts/check-extension-pr.sh runs in extension-ci.yml on pull requests. For each changed extension it warns about three things. The first is a change with no manifest.version bump. The second is a shipped skill with no skills[].folder entry. The third is a webpack frontend (fe/remoteEntry.js with no remoteEntry.json).
• No setup steps in release.yml. The setup-dotnet and setup-node steps are dropped, because the build runs in the builder container.

Why

The DuploCloud upgrader delivers extensions from these releases. It pins each bundle by digest and picks the build whose sdkVersion matches the host. A mutable release, a tag on the wrong commit, or a rebuild at an unchanged version would each break that. The fixes land here and not in each repo, because upgrade_dev_kit.sh overwrites .github/ and scripts/ in every adopted repo.

How it was verified

• Four new test files cover each rule, and they sit beside the existing ones: tests/test-release-extensions.sh, tests/test-check-extension-pr.sh, tests/test-sdk-digest.sh and tests/test-builder-image.sh. The release and PR scripts run against a throwaway git repo with a stubbed gh. The digest is checked against an independent Python computation.
• All nine test files pass.
• actionlint is clean on the workflows. shellcheck is clean on every changed script, apart from one info-level note on a line of build-extension.sh this PR does not change.
• A real build is not yet shown here. A trial PR in an extension repo will confirm the stamped sdkDigest and the warnings on a real build.