feat(podman): align managed-container labels with Docker and Kubernetes

[elezar]

User Story

As an OpenShell operator or integration author, I want compute drivers to expose one consistent managed-container label contract, so that automation can discover and manage Docker, Podman, and Kubernetes resources without driver-specific selectors.

Problem Statement

Podman marks managed containers with openshell.managed=true, while Docker and Kubernetes-oriented resources use the canonical openshell.ai/managed-by=openshell label. This historical mismatch forces operational tooling and end-to-end tests to special-case Podman and makes cross-driver resource discovery error-prone.

Impact / Why This Matters

Today, users and maintainers must know which driver created a resource before selecting it by label. Reusing the Docker/Kubernetes selector against Podman finds no containers, which can cause lifecycle checks and cleanup automation to miss live sandboxes. Keeping two contracts also increases the chance that future tooling silently handles only a subset of drivers.

Proposed Design

Adopt openshell.ai/managed-by=openshell as the common externally observable managed-resource label for Podman, Docker, and Kubernetes. First determine whether legacy Podman container discovery is a supported compatibility obligation at this pre-beta stage. #2565 explicitly tracks the final coordinated breaking-change pass before 0.1.0; if no compatibility guarantee applies, replace the Podman label directly and update all in-repository consumers. If compatibility is required, use a temporary dual-label and dual-discovery migration with documented retirement criteria.

Acceptance Criteria

• Decide and document whether existing openshell.managed=true Podman containers require compatibility support, with the decision aligned to Stabilize public API, SDK, and extension contracts for 0.1.0 #2565.
• Newly created Podman sandbox containers expose openshell.ai/managed-by=openshell.
• If compatibility is required, Podman discovery, cleanup, reconciliation, and test helpers recognize both labels, with coverage for legacy-labeled containers and explicit retirement criteria.
• If compatibility is not required, replace the legacy label and selector across the Podman driver, tests, and documentation as a coordinated breaking change.
• Docker, Podman, and Kubernetes managed-resource documentation and tests use the canonical selector where applicable.
• Publish an appropriate migration or release note for any externally observable breaking change.

Alternatives Considered

• Retain the driver-specific labels indefinitely. This preserves current behavior but leaves every consumer responsible for per-driver branching.
• Preserve legacy Podman labels through a compatibility window. This protects existing containers, but adds temporary implementation and test complexity.
• Replace the Podman label immediately. This is a viable pre-beta option if Stabilize public API, SDK, and extension contracts for 0.1.0 #2565's contract review determines that existing label-based discovery does not carry a compatibility guarantee.
• Change Docker and Kubernetes to the Podman label. This would spread the non-canonical contract to more integrations rather than converging on the established label.

Agent Investigation

The Podman driver currently emits openshell.managed=true; Docker uses the shared openshell.ai/managed-by=openshell label from openshell-core, and Kubernetes-oriented resources use the same canonical convention. PR #2743 surfaced the mismatch when its Podman E2E state check had to use the Podman-specific selector.

Related: #2565 is the pre-0.1.0 public API, SDK, and extension-contract stabilization tracker, including the final planned breaking-change pass.