namespaceObject binds null on an uncollected Namespace, which failurePolicy Fail turns into a false finding

The problem

namespaceObject binds to a real Namespace only when the scan collected one. Collection is driven by what the framework's controls match (core/pkg/resourcehandler/k8sresourcesutils.go:89 walks rule.Match), not by what the loaded CEL policies need. So celNamespaceObjectFor resolves to nil and the evaluator binds null, and the same control can see a real Namespace under one framework and null under another.

Under failurePolicy: Fail, which every bundle policy uses and which is the default, an unguarded read of that null is an evaluation error, and an evaluation error is reported as a violation. So the scan reports a finding on a workload a real cluster would admit.

It is the one entry in the Known gaps list that is not a safe skip.

Why nothing is broken today

No policy in the vendored bundle reads the variable. That is zero across all 66 policies in v0.14. But it is a property of the bundle rather than of the engine, so a pin bump can end it. #3826 adds a test so that arrives as a failed build instead of as wrong scan results.

What closing it takes

Two parts, because cluster scans and file scans are not in the same position.

A cluster scan can fix the input. Request v1/namespaces when a loaded policy reads namespaceObject. The seam is the same loop at k8sresourcesutils.go:89, and rule.DynamicMatch a few lines below is the existing precedent for a second source of GVRs.

A file scan cannot. The Namespace manifest may simply not be there. So an uncollected Namespace has to be classified as an offline-only failure that IsExpressionError rejects (core/pkg/opaprocessor/cel/evaluator.go:69), the same category as a compile error, so it skips instead of reporting.

Doing only the first leaves file scans producing false findings. Doing only the second trades a false finding for a blind spot on cluster scans where the answer was actually available.

What I am asking

Agreement on the two-part shape before I write it, since getting the classification wrong invents findings on clean workloads. I am happy to take both parts, or just the collection half first if that is easier to review.