Investigate tag-based pinning for sibling-calling actions (immutable releases)

## Context

PR #831 surfaced a scaling concern raised by @ppkarwasz: actions that call sibling sub-actions (e.g. `carabiner-dev/actions/ampel/verify` calling `carabiner-dev/actions/install/*`) currently force us to allowlist **two SHAs per release** — the current version plus the previous version that the sibling refs resolve to (per github/community discussion #26245). This scales as `2 × siblings × versions` and is wasteful against the 1000-pattern org cap.

ppkarwasz's full argument: https://github.com/apache/infrastructure-actions/pull/831#issuecomment-4474700884

## Proposal under evaluation

1. **Ask upstream authors (starting with @puerco / `carabiner-dev`) to enable immutable releases** so their version tags can no longer be moved post-publication.
2. **Ask the same authors to pin sibling sub-action refs by tag** instead of by previous-version SHA.
3. **Teach our verifier (`gateway/gateway.py` and friends) to accept tag-pinning when the tag is provably immutable**, ideally with a pattern like `owner/repo/sub-action@vX.Y.Z` rather than `@`.

## Open questions to resolve before implementing (3)

- **Path-segment wildcards.** Does GitHub's org allowlist actually expand patterns like `carabiner-dev/actions/*@v1.2.0`? All current wildcards in `approved_patterns.yml` are version-side (`@*`). If path wildcards aren't supported, the saving shrinks to "one pattern per (sub-action, version)".
- **Immutability re-verification.** GitHub's per-release "immutable" flag can be disabled by the repo owner on future releases. Either:
- Re-check immutability at every audit run (network cost, rate-limit cost, requires API endpoint), or
- Snapshot the flag at approval time and accept silent erosion of the guarantee.
- **Policy update.** README currently says "Always pin actions to exact commit SHAs, never use tags or branch references." Tag-pinning under immutability is a controlled exception — needs to be documented as such, not as a blanket relaxation.
- **Threat model delta.** What's the additional blast radius if a repo turns off immutable releases after approval and an attacker then moves a tag we've trusted? Compare against current SHA-pinning baseline.

## Non-goals

- Replacing the current SHA-pinning policy as the default. SHA-pinning remains the strictly safer primitive; this is about a documented escape hatch for the sibling-action case.

## Suggested next step

Pre-work spike to answer the path-wildcard question (1–2 hour test against a sandbox repo's allowlist). The answer flips the cost-benefit on (3) substantially.