Handle optional resource identity in OpenTelemetry mappings

[thbertoldi]

Fix native OpenTelemetry mappings that fail on legitimate resources without service.namespace or k8s.cluster.name. The platform Collector's own metrics reproduced both missing-key errors; non-Kubernetes services now receive consistent canonical identities without invented Kubernetes metadata.

Scope: this is an independent base-StackPack robustness proposal, not a prerequisite for properly enriched Kubernetes AI telemetry. A follow-up offline replay of three captured real demo resources through all eight changed mappings returned identical outputs on upstream f02ffd7 and this patch (24 comparisons, no errors). Our Collector should continue supplying real service/instance identity and Kubernetes metadata according to the standard integration. The platform self-scrape still fails the upstream mappings after namespace normalization because k8s.cluster.name is absent; its own Collector pipeline could instead enrich that Kubernetes source. Legitimate non-Kubernetes sources require an explicit upstream decision on handling absent Kubernetes attributes. The live tenant still has these eight mapping fixes applied; a full live acceptance run on unmodified mappings has not been performed. This PR remains a draft for upstream review.

• Guard absent/empty resource attributes in service, instance, and namespace mappings, using the existing default namespace fallback consistently.
• Require real service/instance identity in provided-by and infrastructure relations, preventing dangling targets created by substituting a service name for a missing instance ID. Preserve valid existing identifiers and avoid duplicate namespace labels.
• Add CEL regression cases and gate packaging on them. Update the validator to a compatible pinned image, invoke its validator entrypoint directly, and require invalid CEL to fail. Bump the companion source version to 0.1.6.

Validation: eight regression tests pass; the unchanged baseline fails the same cases. All 140 settings across the repository validate, invalid CEL is rejected, and pre-commit, version checks, and packaging pass. Exactly eight reviewed mappings were applied to an installed 0.1.4 companion without upgrading unrelated settings. A real non-Kubernetes HTTP service completed 161 requests with populated charts, trace correlation, and healthy monitors; fresh Kubernetes inference preserved all 14 demo component IDs and 22 relationships. All nine active base mapping statuses and 13 AI statuses cleared, with zero new mapping errors during 341 seconds of continued processing.

Seven mappings without live cloud/function/asynchronous inputs return no status and are not claimed runtime-verified. Existing Kubernetes synchronization duplicate IDs remain separate. Status errors initially outlived the changed mappings and cleared without a reset; error timestamps, input identity, and mapping revision remain a platform diagnostic gap. The package itself was not uploaded during validation.

Related: SUSE AI StackPack v2 and Collector configuration. The counts above describe base-fix validation; the AI PR separately removes four logical usage edges from the communication topology.