Proposal: inherited organization and enterprise Action locks

Is inherited Action-lock configuration in scope for the Workflow Dependency Pinning technical preview?

It would be useful for organization and enterprise owners to provide centrally managed Action-lock entries and require selected repositories to use an effective lock, even when those repositories do not contain `.github/workflows/actions.lock`.

For each action reference, resolution could follow:

```text
repository lock > organization lock > enterprise lock
```

This would let central owners roll out reviewed, known-good Action pins without a repository-by-repository migration. A repository could inherit the organization or enterprise resolution without a local lockfile. Repository administrators could add a local lock entry when they need a permitted repository-specific resolution, or when they introduce an action/ref that is not covered by the organization or enterprise lock.

An organization or enterprise policy/ruleset could require an effective lock for selected repositories. Once enabled, a dependency missing from all applicable lock scopes should fail rather than resolve a mutable tag or branch live.

A practical rollout could be:

```text
audit → generate and review central-lock entries from existing workflow dependencies → enforce
```

The generated central entries should capture the verified resolution at generation time. After enforcement, newly introduced references would require an approved central entry or a permitted repository-level entry.

This appears to need GitHub Actions service/policy and runtime support in addition to `gh-actions-lock`. I’m filing it here because it is related to the technical preview, but please redirect me if there is a better tracker for the broader design.

No repository file, test, or entry point is named. Start by comparing the requested inherited-lock behavior with gh-actions-lock's current generation and verification scope, then determine which parts require GitHub Actions service or policy support. Done means an agreed implementation scope or a redirect to the appropriate tracker.

Written by the indexing model from the issue text.