feat: allow configuring Kubernetes API server

[tn20000]

Summary

Add an optional --apiserver flag so the network policy agent can use a Kubernetes API endpoint that does not depend on kube-proxy programming the Kubernetes Service ClusterIP. The default behavior is unchanged.

Fixes #659.

Changes

• Bind the existing RuntimeConfig.APIServer field to --apiserver.
• Build the REST config through the existing in-cluster or kubeconfig path, then override only its host so authentication and TLS settings are preserved.
• Document the flag and add focused tests for default behavior, flag parsing, host override, and credential/CA preservation.

Test Plan

• Focused unit tests exercise the runtime configuration entry point:

$ go test ./pkg/config -count=1 -v
=== RUN   TestRuntimeConfigBindFlags
--- PASS: TestRuntimeConfigBindFlags (0.00s)
=== RUN   TestBuildRestConfig
--- PASS: TestBuildRestConfig (0.00s)
PASS
ok  github.com/aws/aws-network-policy-agent/pkg/config  0.628s

• Focused static analysis:

$ go vet ./pkg/config

• Repository formatting check:

$ make check-format

• Upstream Linux CI will run the complete build and test suite after a maintainer approves the first-time-contributor workflow run. The full package suite cannot run natively on the development host because unchanged eBPF/netlink dependencies are Linux-only.

Testbox is not applicable to this standalone upstream binary change: no deployment package currently exposes the new argument. The unit tests exercise the changed BuildRestConfig path directly; deployment-level validation belongs with the follow-up VPC CNI/add-on wiring.

Deploy Plan

No direct deployment in this PR. A follow-up change in the VPC CNI/add-on deployment layer must supply the EKS API endpoint through --apiserver where this startup dependency needs to be avoided.