Validate selector representability before label/field pushdown

[ndenev]

Summary

Label/field selector pushdown currently builds selector strings via direct concatenation without an explicit selector-grammar validation step.

This is primarily a robustness/correctness gap (not a security issue by itself): invalid or non-representable values can lead to API parse errors or semantic mismatch between SQL filter intent and Kubernetes selector behavior.

Affected code

• Label selector construction: src/datafusion_integration/provider.rs
• Field selector string conversion: src/kubernetes/field_selectors.rs
• Selector application to API params: src/kubernetes/client.rs (ListParams::labels, ListParams::fields)

Problem

Pushdown classification/extraction should only claim pushdown when filter values are safely representable in Kubernetes selector syntax.

Current code constructs selector text directly (format!, join) and sends it to kube API params without a dedicated representability/validation gate.

Impact

• Query can fail unexpectedly with Kubernetes selector parse errors.
• Potential semantic mismatches if a SQL literal is not safely representable as selector syntax.
• Pushdown contract becomes brittle in edge cases.

Proposed fix

1. Introduce a selector validation/normalization layer before building selector strings.
2. If value/key is not representable in K8s selector grammar:
   • do not push down that predicate (Unsupported or Inexact),
   • let DataFusion apply filtering.
3. Keep URL encoding concerns separate from selector grammar validation.

Tests to add

1. Invalid/edge selector values for labels and field selectors (commas, parens, unsupported key/value forms).
2. Ensure non-representable predicates are not marked as exact pushdown.
3. Regression tests to verify fallback filtering still yields correct results.