atenet router /statusz: Service IP panel is forbidden by the router's own shipped RBAC

## Summary

The atenet router's `/statusz` page (`--status-port`, default 4040) has a "Router Service IP" panel that tries to `get` the `atenet-router` Service via the Kubernetes API — but the RBAC the installer ships for the router's ServiceAccount never grants access to Services. The panel therefore renders a raw forbidden error on every install:

```
Router Service IP
Lookup Failed: services "atenet-router" is forbidden: User "system:serviceaccount:ate-system:atenet-router"
cannot get resource "services" in API group "" in the namespace "ate-system"
```

## Verification (live install, substrate rev 0d85e8572161 on GKE)

The ServiceAccount's only binding is the endpointslices role:

```
$ kubectl auth can-i get services -n ate-system --as=system:serviceaccount:ate-system:atenet-router
no

$ kubectl get role atenet-router-endpointslices -n ate-system -o jsonpath='{.rules}'
[{"apiGroups":["discovery.k8s.io"],"resources":["endpointslices"],"verbs":["get","watch","list"]}]
```

So the statusz code (`cmd/atenet/internal/router/status.go`) calls an API that its own deployment manifests forbid — the panel is dead on arrival, not a cluster-specific misconfiguration.

## Everything else on the page works

For context, the rest of `/statusz` renders fine and is genuinely useful (build rev, port allocation, request-parking state, dataplane / Kubernetes API / ATE API health checks with counters, full CLI args and resolved flags). This is only about the Service IP panel.

## Suggested fix (either)

1. Add `services` `get` (scoped to the router's namespace, arguably even `resourceNames: [atenet-router]`) to the `atenet-router-endpointslices` role — or a small dedicated role, since the existing one is named for endpointslices; or
2. Drop the API lookup: the page already knows the namespace, and the Service IP could be injected via env/downward-API-adjacent means at deploy time, avoiding the extra RBAC surface for a display-only field.

Option 2 keeps the router's RBAC minimal, which the current single-purpose role suggests was the intent.