Warn or block when OCI storage uses result-derived registry without storage.oci.repository

Summary

When OCI storage is enabled without storage.oci.repository, Chains derives the destination registry from TaskRun results (*IMAGE_URL / *IMAGE_DIGEST). This means pipeline authors control which registry host the Chains controller makes outbound requests to — an SSRF/egress concern in multi-tenant clusters.

The storage.oci.repository config already mitigates this by overriding result-derived registries, but it's not required and there's no warning when it's absent.

Proposal

1. Log a warning at controller startup when OCI storage is enabled without storage.oci.repository configured — something like: "OCI storage is using result-derived registries. In multi-tenant deployments, set storage.oci.repository to restrict the destination registry."
2. Consider a future option like storage.oci.allow-result-derived-registry: true|false (default true for backwards compatibility) that lets operators explicitly opt in or out of result-derived registries.

Context

Validated on a live cluster: a TaskRun with IMAGE_URL pointing to an internal service caused the Chains controller to make outbound OCI registry requests (GET /v2/, GET /v2/.../manifests/...) to that host from the controller's network context.

The existing storage.oci.repository config is the right fix, but it should be framed as security-critical for multi-tenant deployments in documentation (#1661).

Related: #1661 (trust model documentation)

/kind feature

Start by tracing the controller startup path and OCI storage configuration handling, focusing on how the absence of storage.oci.repository is detected. Confirm the existing result-derived registry behavior and identify the project’s relevant logging or test entry points. Done means a warning appears when OCI storage is enabled without the repository setting, without changing existing behavior.