1. Proposed title of this feature request

PinnedImageSet: Support multi-segment repository paths

2. What is the nature and description of the request?

Currently the PinnedImageSet API restricts 

https://github.com/openshift/api/blob/master/machineconfiguration/v1alpha1/types.go#L9

quay.io/openshift/image@sha256:abc... 

and 

spec:
  pinnedImages:
    - name: 'quay.io/openshift/hasan/cetiner@sha256:34dxx'

fails due the regex introduced above. 

3. Why does the customer need this? (List the business requirements here)

• Enterprise Registry Organization
     - Large organizations use hierarchical repository structures to organize 
       images by department, team, and project (e.g., quay.io/company/dept/team/project/image)
     - Current limitation forces customers to either flatten their registry 
       structure or avoid using PinnedImageSet entirely
• Multi-Tenant Registry Management
     - Customers using Quay Enterprise or Harbor with multi-tenant configurations
       organize images with multiple path segments for access control and organization
     - Example: registry.io/organization/business-unit/team/application/service
•  CI/CD Pipeline Integration
     - Automated build systems generate images with deep path hierarchies based 
       on branch structure or organizational hierarchy
     - Example: registry.io/company/product/environment/branch/image
     - Inability to pin these images blocks adoption of PinnedImageSet in 
       automated workflows
•  Compliance and Governance
     - Security and compliance requirements mandate specific registry path 
       structures for tracking and auditing
     - Customers cannot use PinnedImageSet for compliance-critical workloads 
       without this support
• Migration from Other Platforms
     - Customers migrating from other container platforms (Docker Hub organizations,
       Azure Container Registry, GCP Artifact Registry) bring existing multi-level
       repository structures
     - Current limitation creates migration barriers

CUSTOMER IMPACT:
Without this feature, customers must choose between:

• Using their preferred registry organization structure WITHOUT PinnedImageSet
• Reorganizing their entire registry to accommodate the single-segment limitation
• Manually managing image pinning outside of OpenShift's native capabilities

4. List any affected packages or components.

• openshift/api
• openshift/machine-config-operator