Make pr_validation resolve internal actions and config from its called workflow ref

[hdamker]

Problem description

pr_validation does not currently use the tooling ref by which the reusable workflow itself is called consistently end-to-end.

A caller can reference a non-v0 ref of camaraproject/tooling, but pr_validation still hardcodes internal dependencies to v0, for example:

• camaraproject/tooling/shared-actions/validate-release-plan@v0
• checkout of linting configuration with ref: v0

As a result, changing the caller ref does not fully move pr_validation behavior to the selected tooling ref.

This makes branch-based or SHA-based pilot testing harder than necessary and differs from the mechanism already introduced for release automation in tooling PR #111, where the reusable workflow resolves its own repository/ref from OIDC claims (job_workflow_ref, job_workflow_sha) and then uses that ref consistently for internal scripts and shared actions.

Possible evolution

Make pr_validation follow the same general ref-consistency model as release automation.

Concretely, pr_validation should resolve or receive the effective tooling ref once and then use it consistently for:

• internal shared actions
• scripts
• configuration checkout

Possible implementation options:

• use the same OIDC-based resolution pattern as release automation
• introduce an explicit tooling-ref input and apply it consistently everywhere internally
• use another equivalent mechanism that guarantees internal ref consistency

Alternative solution

Keep the current @v0 internal pinning and require testing only after publishing to v0 or another shared stable ref.

This avoids change in the short term, but makes coordinated pilot work and branch-based testing unnecessarily difficult.

Additional context

This was identified while discussing pilot support for Commonalities consumption and bundling, but it is a general tooling improvement and should stay separate from Commonalities-specific validation changes.

The scope of this issue is ref consistency only, not validation behavior changes.

[hdamker]

Deprioritizing this. Validation Framework v1 (ReleaseManagement#447) deploys as a separate workflow alongside v0, so fixing ref consistency in v0 is no longer on the critical path. The v1 architecture addresses this from the start. #121 is complete and can still be merged as-is if needed, but is not urgent.