`fleet monitor`/`analyze` report `content_not_found` for every BundleDeployment when OCI storage is enabled

[sestegra]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

On a healthy cluster where bundle contents are stored in an OCI registry
(ocistorage secret in the workspace namespace), fleet monitor reports a
content_not_found issue for every BundleDeployment, and fleet analyze
surfaces them as inconsistencies:

$ fleet monitor -n fleet-default | jq '.diagnostics, .contentIssues'
{
  "contentIssuesCount": 3
}
[
  {
    "namespace": "cluster-fleet-default-<cluster>-<hash>",
    "name": "demo",
    "contentName": "s-8d0c3a246da2dc0ac872f419c0b59a960481ade4fb32d06ce6cfba66b28f6",
    "issues": ["content_not_found"]
  },
  ... one per BundleDeployment ...
]

$ fleet analyze --no-color snapshot.json
DIAGNOSTICS SUMMARY
  ...
  Inconsistencies:                            3  ⚠
    - GitRepo/Bundle Mismatches:              0
    - Content Issues:                         3

The GitRepo, its Bundle and all three BundleDeployments are Ready, the
workload is deployed, and spec.ociContents: true is set on every
BundleDeployment. There is no Content object because, by design, there
should not be one.

Expected Behavior

No content issues for BundleDeployments whose contents live in the OCI
registry or, if the check is kept, one that verifies the OCI artifact secret instead.

Steps To Reproduce

1. Create an ocistorage secret in the workspace namespace so bundle contents are pushed to a registry.
2. Deploy any GitRepo to one or more clusters and wait for Ready.
3. kubectl -n cluster-<ws>-<cluster>-<hash> get bundledeployment <name> -o yaml | grep ociContents
   → ociContents: true, and no Content object exists for that
   deploymentID.
4. fleet monitor -n <workspace> | jq '.diagnostics' →
   contentIssuesCount equals the number of BundleDeployments.

Environment

- Architecture: amd64
- Fleet Version: v0.16.1 (CLI, controller and agents)
- Cluster:
  - Provider: RKE2
  - Options: bundle contents stored in an OCI registry
  - Kubernetes Version: v1.36.4+rke2r1 (Debian 12, containerd 2.3.4)

Logs

Anything else?

Suggested fix

Skip the three content checks (content_not_found,
staged_content_not_found, applied_content_not_found) when
bd.Spec.OCIContents is true:

for _, bd := range bundleDeployments {
    if bd.Spec.OCIContents {
        // contents live in an OCI registry; there is no Content object
        continue
    }
    ...
}

Optionally, report a real OCI problem instead: the agent needs the
<contentID> secret of type fleet.cattle.io/bundle-oci-storage/v1alpha1
to be present in the BundleDeployment's cluster namespace, so a missing
secret there is the OCI equivalent of content_not_found.

Related: --issues never shows content issues

Independently of the false positive, the same snapshot produces two
contradictory outputs:

$ fleet analyze --no-color snapshot.json | grep Content
    - Content Issues:                         3
$ fleet analyze --no-color --issues snapshot.json
=== ISSUES DETECTED - ... ===

✓ No issues detected!

OutputIssues has no branch for content issues; ContentIssuesCount only
appears in the summary counter:

• https://github.com/rancher/fleet/blob/v0.16.1/pkg/troubleshooting/analyzer.go#L145-L305 (OutputIssues)
• https://github.com/rancher/fleet/blob/v0.16.1/pkg/troubleshooting/analyzer.go#L454-L457 (counted in the summary)

Whatever is decided about the OCI case, those two views should agree.