Migrate away from (now retired) nginx-ingress

Our reverse-proxy in the kube is powered by [nginx-INGRESS](https://github.com/kubernetes/ingress-nginx/) (repo archived). This project [has been retired](https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/) and is not receiving any release or update from now on (March 2026).

We thus have to choose an alternative either switching to another [IngressController](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) or one adopting the new [GatewayAPI](https://gateway-api.sigs.k8s.io/guides/getting-started/introduction/). It is important to note that many implementations exist both as IngressClass and GatewayAPI.

From my very brief look at the documentations, Gateway is the way to go. Not only because it's the successor of IngressClass but because it moves a lot of the value from custom-to-implementation config (in annotations snippets in our case) to API-defined rules and props. Implementations then handle the details.

Also important is that we rely a lot on nginx-ingress's annotations (custom nginx config snippets). What this means is that there's no shortcut to expect in switching to another IngressClass: we'd have to port all our logic (but into an implementation-specific manner).

Initial step would be to map our specific needs and check if all can be handled by the Gateway API as is. If not, we should identify and handle differently. We should then identify and/or test an implementations. Following our principles of simplicity, reliability and performance (FOSS obviously), it seems [Varnish](https://gateway.varnish.org) and [HAProxy](https://haproxy-ingress.github.io/docs) are good candidates but there are many others.

> [!WARNING]
>
> k8s `1.35` is the last version supported by nginx-ingress.
> We thus cannot update our cluster to `1.36` (released in April 2026) without this.
> Scaleway forces us to upgrade before **July 7, 2027** (auto-upgrades on September 7).
> We thus **have to migrate** before that but that doesn't mean we should wait until last minute.
> It's **a lot of work** but it apparently [can be tested in parallel and there are tools](https://gateway-api.sigs.k8s.io/guides/getting-started/migrating-from-ingress-nginx/) to help.

Start by mapping the current nginx-ingress requirements, especially the custom annotations and configuration snippets, then read the linked Gateway API migration guidance. Compare those requirements with Gateway API and candidate implementations such as Varnish or HAProxy. Done means a replacement is selected, tested in parallel, and the existing reverse-proxy behavior is migrated and validated.

Written by the indexing model from the issue text.