gateway: README and godoc statements about passthrough listeners that do not match the code #4827

Several statements in the gateway chart README and the TenantGateway godoc no longer match the code. Review of #4638 turned them up. They were already wrong before that PR or became wrong because of it, and were left out to keep that PR's scope. Each item below is checked against the code on the #4638 head.

1. packages/extra/gateway/README.md, passthrough limitations: "a shape this platform has not run before: a passthrough listener declared with no TLSRoute behind it". Until feat(gateway)!: reserve a passthrough listener's name by the spec alone #4638 every non-edge tenant rendered tls-api, tls-vm-exportproxy and tls-cdi-uploadproxy with no route attached, so the platform has run that shape all along.
2. Same README, the paragraph on adding tlsPassthroughListeners by hand, says the Helm version helm-controller carries "is not pinned in this tree". It is pinned: internal/fluxinstall/manifests/fluxcd.yaml ships helm-controller v1.5.0, which installs new releases with server-side apply. The createPatch reasoning in that paragraph covers only client-side apply. The conclusion (a hand-set key is not reverted) still holds under SSA, the reasoning is incomplete.
3. Same README, security model, item 1: "the native-port ones rest on Cilium implementing neither TCPRoute nor UDPRoute". Cilium 1.20.2 does implement TCPRoute (getSupportedRouteKinds maps TCP to TCPRoute). The conclusion is still right for another reason: a TLS listener admits only TLSRoute. The Go comment in reconciler.go already says this; the README copy does not.
4. The godoc of TLSPassthroughServices in api/gateway/v1alpha1/tenantgateway_types.go does not say that under http01 the listener's name is reserved by the spec alone. tlsPassthroughListeners says so, and kubectl explain on the services field shows nothing about it.
5. The README does not mention the upgrade window for child tenants. If the new cozystack-controller runs before a child's gateway chart is upgraded, the child still carries the old tlsPassthroughServices, so its own HTTPRoute on api.<child-apex> loses its listener until the chart catches up. The Certificate is collected and the Secret is adopted again afterwards, with no new ACME order.
6. Not prose, but found the same way and present before feat(gateway)!: reserve a passthrough listener's name by the spec alone #4638: an HTTPRoute with a free hostname and a refused wildcard hostname reads Accepted=False as a whole, although the free name gets a listener. acceptPartlyReserved from feat(gateway)!: reserve a passthrough listener's name by the spec alone #4638 relaxes this only when the reservation is the sole cause. I found it by reading judgeHTTPRouteClaim and updateRouteStatuses; there is no test for it.

The README and the comments in reconciler.go also still describe cilium/cilium#45559 in the present tense. That goes away with the cleanup tracked in #3087, so it is not repeated here.