Unable to create HTTP-to-HTTPS redirects (with custom FQDN)

In order to evaluate Lattice I need to replicate existing behaviour such as HTTP-to-HTTPS redirects.

Consider this example in the Gateway docs: https://gateway-api.sigs.k8s.io/guides/http-redirect-rewrite/#http-to-https-redirects

I've created the following:
```yaml
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: lattice
spec:
gatewayClassName: amazon-vpc-lattice
listeners:
- name: http
protocol: HTTP
port: 80
- name: https
protocol: HTTPS
port: 443
tls:
mode: Terminate
certificateRefs:
- name: unused
options:
application-networking.k8s.aws/certificate-arn:
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: example-http
spec:
hostnames:
- example.com
parentRefs:
- name: lattice
sectionName: http
rules:
- filters:
- type: RequestRedirect
requestRedirect:
scheme: https
statusCode: 301
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: example-https
spec:
hostnames:
- example.com
parentRefs:
- name: lattice
sectionName: https
rules:
- backendRefs:
- name: example-svc
port: 80
```
However what happens is one Service gets created and associated with the ServiceNetwork, (the HTTPS one in my case), and then the other Service is created but cannot be associated by the controller due to there already being a Service associated with the same custom FQDN.

What I'd expect is (somehow) one Service with two listeners, which incidentally is what I get if I just create one HTTPRoute for both HTTP and HTTPS with no redirect.

It strikes me this won't even work if I removed the custom FQDN as it would just create two Services with different .on.aws FQDNs unrelated to one another.

This seems like a fairly critical blocker unless I'm misunderstanding something?

Reproduce the reported behavior with the Gateway, HTTPRoute, custom FQDN, and certificate manifests in the issue. Trace how the controller creates Services and associates them with the ServiceNetwork for separate HTTP and HTTPS routes; done means HTTP-to-HTTPS redirects work without conflicting Service associations, including without a custom FQDN.

Written by the indexing model from the issue text.