fix(api): dynamically resolve backend URL for in-cluster deployments.

[Utkarshpandey0001]

fixes #102

fix: resolve backend API url dynamically from browser origin

The Inspektor Gadget plugin contained an architectural flaw in how it resolved its backend API endpoint. The getServerURL() function was hardcoded to return http://localhost:4466 for all non-Docker Desktop environments. Because of this, when the plugin was used in any standard Kubernetes web deployment (like EKS, GKE, or Bare-metal), it incorrectly attempted to route its internal API traffic to the user's local machine, causing fatal ERR_CONNECTION_REFUSED errors when attempting to use any gadgets.

This PR addresses the issue by modifying getServerURL() to accurately check for the desktop application environments (isDockerDesktop() and isElectron()), and safely returning an empty string "" for everything else (in-cluster browser clients).

By returning an empty string, we allow the fetch and WebSocket calls across the plugin codebase to safely resolve via relative paths. This empowers Headlamp's environment-aware API proxying to correctly route the traffic straight into the backend service regardless of the deployment configuration.

How to use

Reviewers can validate this PR by doing the following:

1. Deploy Headlamp with this plugin branch built into a remote Kubernetes cluster.
2. Access the Headlamp UI in your browser via the remote domain or IP.
3. Navigate to the "Gadgets" or "Resource Gadgets" section and attempt to attach or run a gadget instance.
4. Verify that the browser network tab successfully connects to /plugins/.../ or /externalproxy endpoints without throwing ERR_CONNECTION_REFUSED on localhost endpoints, and confirm that the gadget streams data successfully.

Testing done

All code formatting, linting, and TypeScript compilation CI workflows were successfully validated locally on the branch. Testing outputs are fully green.

npm run format && npm run lint && npm run tsc && npm run test