Store Azure project coordinates without Kubernetes label-value restrictions

## Problem

AKS Desktop persists Azure subscription and resource-group coordinates in project namespace labels so shared project features can resolve Azure context consistently. AKS Hybrid & Edge project creation intentionally writes the same metadata for parity with existing managed namespaces.

Azure resource-group names do not always fit Kubernetes label-value syntax: they may contain characters such as parentheses and may be up to 90 characters, while Kubernetes label values are limited to 63 characters and a smaller character set. A native Kubernetes Namespace can therefore reject otherwise valid Azure coordinates.

This is a general project-metadata compatibility issue, not specific to the Hybrid & Edge feature. Existing readers across Access, Info, Metrics, Scaling, capability, deletion, import, and project detection currently consume the label.

## Proposed direction

- Define annotations for exact Azure subscription and resource-group coordinates.
- For native namespaces, write the exact values to annotations.
- Preserve existing labels when values are Kubernetes-label-safe for backward compatibility and managed-namespace parity.
- Update readers to prefer annotations and fall back to legacy labels.
- Keep existing managed AKS namespace behavior compatible.
- Define migration behavior for existing namespaces and imported projects.

## Acceptance criteria

- Project creation succeeds for resource-group names containing parentheses and for names longer than 63 characters.
- All current project features resolve the exact resource group from annotation-first metadata.
- Existing label-only managed and imported projects continue to work.
- Deletion and un-project flows remove both label and annotation metadata where appropriate.
- Tests cover label-safe names, invalid label characters, long names, and legacy fallback.

Follow-up from #782.

Trace project namespace creation, detection, import, deletion, and un-project paths, focusing on the Access, Info, Metrics, Scaling, capability, and project-detection readers named in the issue. Review how current Azure labels are written and consumed, then run the existing project and namespace tests. Done means native projects accept invalid or long resource-group names, readers prefer exact annotations with legacy-label fallback, and metadata cleanup remains compatible.

Written by the indexing model from the issue text.