feat(042): serve telemetry payload via REST, require daemon for show-payload (#376)

Before this change, `mcpproxy telemetry show-payload` built an offline
telemetry service with no runtime stats attached, so the printed
heartbeat had zero values for server_count, connected_server_count,
tool_count, uptime_hours, routing_mode, surface_requests,
builtin_tool_calls, rest_endpoint_calls, error_category_counts,
and doctor_checks — misleading to anyone auditing what we send.

Changes:
- Add GET /api/v1/telemetry/payload handler that calls
  runtime.TelemetryService().BuildPayload(), so the payload reflects
  live runtime stats. Returns 503 when telemetry service is nil.
- Wire a SetTelemetryPayloadProvider setter from internal/server/server.go
  so the handler always resolves the current telemetry.Service.
- Add cliclient.Client.GetTelemetryPayload() mirroring GetDiagnostics.
- Rewrite runTelemetryShowPayload to mirror the doctor pattern:
  load config for DataDir, detect the socket, error out with
  "telemetry show-payload requires running daemon. Start with:
  mcpproxy serve" when unavailable, otherwise call the new endpoint.
- Unit tests: handler 200/503 cases; cliclient success and 503 cases.
- Regenerate oas/swagger.yaml + oas/docs.go for the new route.

`telemetry status`, `enable`, and `disable` remain offline-capable
and are intentionally not touched.

Co-authored-by: Claude Code <noreply@anthropic.com>