feat(raster-serving): upgrade mapproxy chart to 2.2.0

[razbroc]

Draft - blocked. mapproxy 2.2.0 is not published yet. Do not merge until MapColonies/docker-mapproxy#103 is released and the chart is pushed to ACR, otherwise helm dependency build in build-and-push-helm.yaml will fail.

What

Bumps the mapproxy dependency in charts/raster-serving/Chart.yaml from 2.1.3 to 2.2.0.

Why

The mapproxy chart renders two containers from a single merged tracing.url, but they do not speak the same OTLP transport:

container	exporter	needs
mapproxy (python)	opentelemetry.exporter.otlp.proto.grpc	host:4317, no path
mapproxinator (node)	@opentelemetry/exporter-trace-otlp-proto (HTTP)	host:4318/v1/traces

So whichever port is configured, one container silently drops every span. Confirmed on the live raster-dev deployment: probing from inside the running mapproxinator container returned FAILED (HPE_INVALID_CONSTANT) against :4317 and HTTP 200 against :4318/v1/traces, while mapproxy logged [otel-probe] collector REACHABLE at ...:4317.

MapColonies/docker-mapproxy#103 adds an opt-in mapproxinator.tracing.url that overrides the shared endpoint for that container only. This bump makes it available to raster-serving consumers.

Version note

2.2.0 assumes #103 lands as a feat under release-please. If a reviewer retitles it to fix, this becomes 2.1.4 and I will update this PR.

The chart's own version: is untouched - charts/raster-serving is a release-please package (release-type: helm), so it owns that bump.

Verification

None possible yet: helm dependency build cannot resolve 2.2.0 until it is published. This PR stays a draft until then, at which point I will validate and mark it ready.

Chain

1. feat(helm): allow a separate OTLP endpoint for the mapproxinator container docker-mapproxy#103 - add the chart override (open)
2. this PR - make it available to raster-serving (blocked on 1)
3. MapColonies/site-values#289 - set the HTTP endpoint for mapproxinator (blocked on 2)