fix(pack-release): make tag-paths optional for charts without first-party images

[oren-openteams]

Summary

Make tag-paths optional in pack-release.yaml. Currently the workflow assumes every caller has at least one first-party (org-owned) image tag to pin to sha-<short> at release time. Charts that don't ship any first-party images — e.g. wrappers around third-party charts that only reference upstream base images — can't use this workflow today: passing tag-paths: "" (or omitting the input) fails the "Pin image tags to release sha" step.

Root cause

pin_image_tags.py:70-75 validates len(argv) < 4 and exits 2 when no paths are provided. The workflow step calls the script with [script, values-file, sha-tag] (three args, no paths), triggering the usage-message exit path. The step fails, and everything downstream (Set up Helm, Package chart, Create GitHub Release, Sync to helm-repository) is skipped.

Fix

Two additive changes to pack-release.yaml:

1. tag-paths input becomes optional — required: false, default: "". Documented in the input's description block.
2. Guard the script invocation in the "Pin image tags to release sha" step: skip the pin_image_tags.py call and log a "nothing to pin" message when the parsed paths array is empty.

The pin_image_tags.py script itself is unchanged — its strict argv check remains a useful guard against typos when tag paths are declared. The change is entirely at the workflow layer.

Behavior after this PR

Caller passes…	Before	After
tag-paths: "operator.image.tag"	script pins operator.image.tag	unchanged
`tag-paths: "operator.image.tag
worker.image.tag"`	script pins both	unchanged
tag-paths: ""	❌ fails at pin step	✅ logs skip, continues
input omitted entirely	❌ workflow rejects (required)	✅ same as empty string

Test plan

• Existing callers with populated tag-paths continue to pin as before (script argv is identical; script logic unchanged).
• Charts calling this workflow with no tag-paths proceed through package → release → helm-repository sync without touching values.yaml.

Motivation

Some charts in the ecosystem legitimately don't ship first-party images — for example, a chart that wraps a third-party operator and configures it via values without shipping any bespoke worker image. Those charts should still benefit from the shared release automation (consistent tag naming, auto-publish to nebari-dev/helm-repository, idempotent re-runs).

After merge

Once this merges to main, the v1 tag needs to move to include this commit so downstream consumers pick up the fix. Assuming v1 continues to be maintained as a mutable "latest v1.x" pointer (currently v1 == main), no consumer action is needed beyond the next Chart.yaml bump they push.