contour-internal: IP MetalLB jamais assignée (label/annotation internal-network manquants)

## Contexte

Découvert le 2026-08-26 en root-causant un incident DNS OPNsense (zone BIND corrompue + drift HA) : une fois le DNS interne réparé, tout `*.etsmtl.club` cassait en interne parce que l'override wildcard Unbound pointait vers `10.5.0.10`, censée être l'IP LoadBalancer de `contour-internal-envoy` — mais MetalLB ne l'a **jamais assignée**.

## Root cause

Le pool `internal-ip` ([k8s-base/common/internal-ip/ip-reservation.yaml](https://github.com/ClubCedille/k8s-base/blob/main/common/internal-ip/ip-reservation.yaml)) a `addresses: []` par défaut, rempli via l'annotation `etsmtl.club/internal-ip` sur le Secret cluster ArgoCD — mais le cluster `k8s-shared` n'a **jamais eu** :
- le label `etsmtl.club/internal-network: "true"`
- l'annotation `etsmtl.club/internal-ip: 10.5.0.10`

dans `system/argocd/kustomization.yaml` de ce repo (seul le côté `external-network`/`external-ip` y est configuré). Donc `contour-internal-envoy` reste `` en permanence sur ce cluster, probablement depuis toujours — indépendamment de l'incident DNS du jour.

## Fix tactique déjà appliqué (pas la cause racine)

Sur les deux OPNsense, le split-horizon `*.etsmtl.club` a depuis été simplifié : plus de forward-zone dédiée ni de wildcard override, tout `*.etsmtl.club` route maintenant via le fallback public normal (`142.137.247.75` via le wildcard Cloudflare). Ce n'est donc plus bloquant en pratique, mais le split-horizon interne (trafic intra-cluster/intra-VLAN via IP privée plutôt que via l'IP publique) reste cassé.

## Ce qu'il faut faire

Ajouter au `secretGenerator` de `system/argocd/kustomization.yaml` :
- label `etsmtl.club/internal-network: "true"`
- annotation `etsmtl.club/internal-ip: 10.5.0.10`

committer et laisser l'ApplicationSet `internal-ips` synchroniser. Une fois `contour-internal-envoy` avec une vraie IP interne, on peut réévaluer si on veut réintroduire un split-horizon DNS propre côté OPNsense.