bug: Stop encouraging bad architecture by routing `/services/` on front-proxy to the root shard

[ntnn]

Describe the bug

The front-proxy is in many places configured to route /services/ to the root shard.

E.g. in the kcp-operator: https://github.com/kcp-dev/kcp-operator/blob/24e13a58f10c384b6b9751f81c3c94d97e9bd5e1/internal/resources/frontproxy/configmap.go#L64-L78
Or in the helm-chart everything is routed as a fallback to the root shard: https://github.com/kcp-dev/helm-charts/blob/ff4b694c715b6fa07f114d4564463e07601ff772/charts/kcp/templates/front-proxy-configmap.yaml#L10-L17

The problem with this is that to users new to kcp it looks like the VWs should be available through the front-proxy and leads to e.g. downstream rewriting the root shard VW URL to the external URL - which of course only works until a second shard is added.
It also lead to a PR rewriting the VW URL to the external URL: #3823

Ideally front-proxy would need no initial mapping, it already has the information for the root shard:

kcp/pkg/proxy/options/options.go

Line 62 in c749f92

fs.StringVar(&o.ShardsKubeconfig, "shards-kubeconfig", o.ShardsKubeconfig, "The path to the kubeconfig used for communication with all shards. The server name if provided is replaced with a shard's hostname.")

And should be able to build its mapping for clusters from there.

I did some smoke tests on the weekend and a bunch of tests failed when the /services/ mapping was gone. I presume that most of these are just the wrong client being used in those tests rather than kcp itself actually failing.

Steps To Reproduce

1. Deploy kcp in any way
2. Access root shard VWs through fp

Expected Behaviour

1. Deploy kcp in any way
2. Fail to access root shard VWs through fp

Additional Context

No response