Add --append-image-name-suffix to pack extension package

[lcampanella98]

Summary

pack buildpack package supports --append-image-name-suffix, but pack extension package does not.

When publishing a multi-arch extension with --publish, pack builds one image per target platform and pushes them before assembling the final image index. Without a suffix, every platform image is pushed to the same tag. On a registry that doesn't allow overwriting an existing tag, the second platform's push is rejected and the publish fails.

This adds --append-image-name-suffix to pack extension package, mirroring the existing buildpack command. When the flag is set on a multi-arch --publish, each platform image is pushed to a distinct [os]-[arch] tag, so no two pushes collide. The final image index is unchanged and still resolves to all platforms. The suffix only applies when the build is multi-arch (len(targets) > 1) and --publish is set.

The change reuses the shared client.PackageBuildpackOptions (it already has the AppendImageNameSuffix field), so it closely mirrors the buildpack code:

• Flag struct field — buildpack_package.go#L33
• Warning when used without --publish — buildpack_package.go#L135-L137
• Passing the option (gated on --publish) — buildpack_package.go#L145
• Flag registration — buildpack_package.go#L174
• Suffix logic in the client — package_buildpack.go#L204-L211

I added unit tests covering that the flag is passed through when publishing and ignored (with a warning) when not. I did not add a client-level test for the suffix itself: the transformation it calls (name.AppendSuffix) is already covered in internal/name, and a multi-arch publish test would need significant new mocking the buildpack path doesn't have either. Happy to add one if preferred.

Output

Publishing the samples cowsay extension to two platforms:

pack extension package <registry>/cowsay --path extensions/cowsay --publish \
  --target linux/amd64 --target linux/arm64 [--append-image-name-suffix]

Before

Only the index tag is created. On a registry that blocks tag overwrites, the publish fails when the second platform pushes to the already-existing tag:

$ curl -s <registry>/v2/cowsay/tags/list
{"name":"cowsay","tags":["latest"]}

# on an overwrite-protected registry:
ERROR: saving image: failed to write image to the following tags:
[<registry>/cowsay: PUT .../manifests/latest: <rejected: tag already exists>]

After

Each platform gets its own tag, so nothing is overwritten and the publish succeeds. latest still resolves to both platforms:

$ curl -s <registry>/v2/cowsay/tags/list
{"name":"cowsay","tags":["latest","linux-amd64","linux-arm64"]}

I verified the failure and the fix against an immutable-tag registry (zot configured to allow creating tags but not overwriting them). The exact rejection text is registry-specific; in my zot setup it surfaced as UNAUTHORIZED, while other registries phrase it as a tag-immutability error. The common behavior is that the second push to an existing tag is rejected.

Documentation

• Should this change be documented?
  • Yes, see #___
  • No

Related

Resolves #2366