StatefulSet ordinal mode can silently leave buckets unowned

## Expected Behavior

StatefulSet ordinal mode should not silently leave configured buckets without owners.

If the bucket count exceeds the number of StatefulSet replicas, Knative should either distribute all buckets across the available replicas or report an actionable configuration error.

## Actual Behavior

Each StatefulSet replica owns only the bucket at its ordinal:

https://github.com/knative/pkg/blob/521cb33b33ddfe74529a68ff564450c051287436/leaderelection/context.go#L224-L246

The configuration provides the pod ordinal but not the StatefulSet replica count:

https://github.com/knative/pkg/blob/521cb33b33ddfe74529a68ff564450c051287436/leaderelection/config.go#L155-L190

With eight buckets and four replicas, four buckets have no owner. All four pods start successfully, but keys hashing to the unowned buckets are never reconciled.

## Steps to Reproduce the Problem

1. Configure leader election with eight buckets.
2. Run the controller in StatefulSet ordinal mode with four replicas.
3. Enqueue keys covering the eight-bucket hash space.
4. Observe that keys assigned to buckets without corresponding pod ordinals are never reconciled.

## Additional Info

The original StatefulSet integration used matching counts—ten replicas and ten buckets:

https://github.com/knative/pkg/pull/1451

A downstream occurrence and current validation workaround are tracked in:

- https://github.com/tektoncd/operator/issues/3957
- https://github.com/tektoncd/operator/pull/3958

One possible design is to supply the replica count explicitly and assign buckets deterministically:

```text
owner(bucketIndex) = bucketIndex % replicaCount
```

This would require defining safe behavior for scaling and rolling updates. If multiple-bucket ownership is not desired, detecting and reporting the unsupported topology would still prevent silent loss of reconciliation.

/area API
/kind bug

Start with leaderelection/context.go at the linked ordinal-owner logic and leaderelection/config.go at the configuration path that supplies the pod ordinal. Run the eight-bucket, four-replica reproduction and trace how ownership is determined. Done means the supported topology cannot silently leave buckets unowned, either by deterministic assignment or an actionable configuration error, with scaling and rolling-update behavior defined.

Written by the indexing model from the issue text.