cosign: auto-detect verify policy from custom Sigstore trusted roots

[stealthybox]

OCIRepository recently added a custom Sigstore
trusted_root.json via .spec.verify.trustedRootSecretRef. This patch makes the
cosign verifier derive its verification policy from the contents of that
trusted root instead of hard-coding it.

This allows the components used in private/custom/3rd-party sigstore stacks to use
the infrastructure components they opt into.

It also adds a self-contained end-to-end test harness that stands up a real
Sigstore stack + TSA on a separate e2e kind cluster + unit tests
for the new policy auto detection.

Behavior

Verification policy is auto-detected from the trusted root:

Trusted root contents	Verification behavior
contains: Rekor transparency logs	Rekor inclusion proof required; all non-empty Rekor baseUrl values are tried deterministically for legacy online lookup
missing: Rekor transparency logs	tlog verification skipped
contains: Timestamping authorities	RFC3161 signed timestamps required
missing: Timestamping authorities	signed timestamps not required
contains: CT logs	keyless signatures require a valid embedded SCT
missing: CT logs	SCT verification skipped

Keyless verification with a custom root requires Fulcio plus at least one durable
time source (Rekor or TSA), preventing acceptance of a keyless signature that has only an
identity certificate with no transparency-log inclusion or trusted timestamp.
(this is an invalid/insecure configuration that we should discourage)

Keyed verification combined with a custom trusted root no longer forces
Offline=true/IgnoreTlog=true; tlog or TSA material in the bundle is verified
alongside the public key. Keyed verification without a custom trusted root keeps
the legacy offline behavior.
Any Fulcio or CTLog that is present in a custom root are ignored during keyed verification.

Design Considerations

This automatic verification policy behavior allows us to support new combinations of
sigstore components without adding new fields to the API.

It is notable that this drifts from the Sigstore spec recommendation. The spec mentions the
trust material/bundle contents should not be considered a verification policy.
The current Flux verification policy is effectively hard-coded to two sets of differing defaults
for keyed and keyless flows. This makes it challenging to evolve the API in a way that behaves
somewhat uniformly when users start passing custom trust material, or in the future if we want
to add an alternative path for per-resource TUF roots. It also complicates the behavior for
controller-level overrides.

Since we cannot break existing behaviors on our GA API's, we basically two implementation options:

• 1. implement this heuristic policy behavior as the default (this patch as it stands),
     then add options in follow-ups for people to opt-in to explicit, more secure,
     sigstore-spec compliant, per-resource/controller-level verification policy
• 2. whenever handling custom roots via brand-new Flux API fields or controller options, we
     have specific hard-coded defaults, but also expose additional fields for whether to require
     or ignore each of the 4 categories of trust material.
     ( some combinations are insecure or should be considered invalid )

This PR does not modify the existing default verification policy for
cosign SDK usage of TUF or sigstore trusted roots via files on the controller filesystem.
(via TUF_ROOT_JSON/SIGSTORE_ROOT_FILE)
For those, additional controller level flags to granularly modify the defaults will be
necessary. The behavior prior to and with this PR is to ignore TSA and require Rekor/Fulcio/CTLog
which is a verification policy that is designed for the public-good instance.

Testing

• Unit tests cover the bundle component detection, CheckOpts mutation, Rekor URL
  extraction (sort/dedupe), and the online Rekor retry loop.
• A new hack/sigstore-test/ harness installs the sigstore scaffold stack
  (Trillian, Rekor, Fulcio, CT log) plus an RFC3161 TSA on kind and runs a
  cosign v2/v3 * key-pair/keyless verification matrix against a live
  source-controller, including negative cases that must report
  Ready=False / VerificationError.
• This runs as a dedicated sigstore e2e job alongside the existing e2e job.

The first commit with test cases cover e2e for the already merged custom root field.
The next commits with the failing tests are intended for the auto-detect behavior.
Then the subsequent commit adds the auto-detect functionality to show that it makes the
tests pass.

Docs

I added to docs/spec/v1/ocirepositories.md for the auto-detection policy table
and multi-instance trusted-root guidance