fix(chart): route /pair to the pairing relay in default HTTPRoute and Ingress rules

[Kampe]

Problem

With pairingRelay.enabled: true, the chart deploys the buzz-pair-relay sidecar and its Service — but neither the default HTTPRoute rules nor the chart-managed Ingress route anything to it. Mobile pairing then fails for every chart user who relies on the chart's own ingress objects:

1. Desktop probes NIP-11 for pairing_relay_url; operators who route ingress themselves may not have a /pair route either way, but chart-managed ingress users get the default / → relay rule only.
2. Whether the advertised URL is wss://<host>/pair or the client falls back to the legacy /pair convention, the request lands on the main relay, which serves no /pair route (router.rs) → WebSocket upgrade 404, pairing dead.

This is the Helm-chart sibling of #2734 / #3291 (same gap in deploy/compose).

Fix

When pairingRelay.enabled:

• HTTPRoute (default rules branch only — explicit httproute.rules stay untouched): add a PathPrefix /pair rule → <fullname>-pairing:<port>. Gateway API prefers the most specific match, so ordering is cosmetic.
• Ingress: append a /pair Prefix path → the pairing Service on every rendered host (longest-path matching peels it off the relay's /).

The pair relay itself ignores the request path (buzz-pair-relay/src/lib.rs: "Routes only /pair to this sidecar… The relay does not enforce path restrictions"), so no rewrite filter is needed.

Verification

• helm unittest: three new cases in networking_test.yaml (no /pair rule when disabled; HTTPRoute default rules gain /pair + keep /; Ingress default host gains /pair). Suite passes.
• Running in production at wss://buzz.yugalabs.io (chart 0.1.6, ArgoCD + Envoy Gateway, equivalent route defined out-of-chart): NIP-11 advertises wss://buzz.yugalabs.io/pair, WS upgrade on /pair returns 101, iOS pairing completes.

Related open PRs/issues: #2734, #3291 (compose-side; this PR is chart-side — none found targeting the chart).