Bug: gh actions-lock rewrote a composite action, but did not lock it #264

I think this is related to #183.

I observed this in astral-sh/uv#23077.

Expected behavior

gh actions-lock should either skip rewriting **/action.ya?ml (unless it's .github/workflows/action.ya?ml) or properly lock it, i.e. include it by reference in the workflow lockfile.

Actual behavior

gh actions-lock appears to have rewritten a local composite action into its unpinned form, but without adding lockfile entries for it. The composite action's own action dependencies appear as dependencies in each calling workflow's lockfile section, but without any indication that they're transitive rather than direct.

zizmor then flags this because workflow lockfiles are per-repo, and it can't guarantee that any external user of the action gets proper hash-pins. In other words, the rewrite degrades the immutability property for external consumers of the action, even if first-party (in-repo) uses are properly locked indirectly.