Proposal: Support using centrally-managed ImagePullSecrets from knative-serving namespace to resolve image tag digest

/area API
/kind feature

## Describe the feature
Currently, Knative controllers expect `imagePullSecrets` to be present in the *user namespace* where a Knative Service/Revision is deployed. This is required for image tag → digest resolution.

In multi-tenant environments, this creates challenges:
- **Duplication:** Org-managed registry credentials must be copied into every namespace.
- **Exposure:** All namespace tenants can read the secrets.
- **Operational overhead:** Rotating/updating secrets requires syncing across multiple namespaces.

### Proposal

Introduce a mechanism to allow Knative controllers to use a centrally-managed `imagePullSecret` from the `knative-serving` namespace (or a configurable global namespace), rather than requiring it in each workload namespace.

Example (per-service opt-in via annotation):

```yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: my-service
namespace: user-namespace
annotations:
serving.knative.dev/use-global-pull-secret: "true"
spec:
template:
spec:
containers:
- image: private.registry.io/app:latest

```
### Expected behavior

If the annotation/label is present, Knative controller reads the global imagePullSecret from knative-serving service account for image resolution.

If not set, existing behavior continues (secret must be present in workload namespace).

**NOTE:** At the host level, containerd is already configured with a secret for private registry authentication, which allows containerd itself to successfully pull images.

### Benefits

- Simplifies secret management in multi-tenant clusters.
- Reduces duplication of secrets across namespaces.
- Improves security by avoiding exposing secrets directly to namespace tenants.

Start by tracing the Knative controllers' image tag-to-digest resolution and their current namespace-scoped imagePullSecrets handling. Review how the knative-serving service account and proposed opt-in annotation would be represented, then define tests for both global-secret opt-in and unchanged behavior when it is absent.

Written by the indexing model from the issue text.