feat: Add support for service.selector override

[Sokkenissen]

Utfordring:

Common chart hardkoder Service-selektoren til app: <release-name>. Dette fungerer fint for enkle deployments, men blir en utfordring når flere Helm-releaser skal dele samme nettverkstrafikk.

Eksempel: canary-deployments. Når vi deployer en pricingservice-canary ved siden av pricingservice, får canary-podene labelen app: pricingservice-canary som ikke blir valgt i rutingen. Det finnes ingen måte å rute produksjonstrafikk til canary-podene på uten å bruke manuell kubectl patch på Servicen, noe som introduserer RBAC-bekymringer rundt github service account, skjørhet rundt Helm-rekonsiliering og operasjonelt overhead ved hver canary-deploy og teardown.

Forslag til løsning:

Eksponerer service.selector som en valgfri overstyring. Når den er satt, erstatter den standard app: -selektoren fullstendig. Når den ikke er satt, er oppførselen uendret.

Dette lar et canary-chart deklarere sin egen selektor som matcher en felles label på tvers av både hoved- og canary-podene

Endringer:

• templates/service.yaml — selektoren faller tilbake til app: når service.selector er tom
• values.yaml — standard service.selector: {}
• values.schema.json — schema-innslag lagt til (påkrevd på grunn av additionalProperties: false)
• tests/service_test.yaml — test verifiserer at egendefinert selektor brukes og at standard app-label er fraværende

Se gjerne over og si hva dere tenker.