Emit Mapping CRDs instead of v1 getambassador.io/config Service annotations

[thomasvangurp]

Problem

Hatchery currently annotates each per-user Service with a v1-Mapping getambassador.io/config blob (see hatchery/pods.go). Emissary-ingress 3.x crash-loops on every Launch because its Service-watcher's v1-annotation parser hits a Go reflect bug:

PANIC: reflect: reflect.Value.Set using value obtained using unexported field
    …
    github.com/emissary-ingress/emissary/v3/pkg/snapshot/v1.convertAnnotationObject

Reproduced on emissary 3.9.1 and 3.12.2. reflect.Value.Set using unexported field is a long-standing Go/apimachinery compatibility issue. Any Gen3 operator running emissary 3.x (the only available stream today — 2.x is EOL) is affected.

Request

Add a config flag (default opt-in) to emit a native getambassador.io/v2 Mapping CRD for each per-user Service, instead of (or in addition to) the legacy annotation. The annotation syntax was effectively deprecated by Ambassador when it became Emissary; CRD-based Mappings are the supported path.

Proposed config key under containers[] or at top level:

{
  "use-mapping-crd": true
}

When true, hatchery would:

1. Skip writing the getambassador.io/config annotation.
2. Create a sibling Mapping CRD with the same routing fields (prefix, service, rewrite, bypass_auth, timeout_ms, use_websocket, headers.remote_user), owned by the Service for GC.

Reference

Tracked downstream in se4bio/gen3-config#10. We're running a tiny bash-in-a-Pod sync controller as a stopgap — happy to contribute the hatchery patch once there's interest.