feat(gateway): Auto-create ServiceNetwork on Gateway creation

[abdallahmahran10]

Summary

Auto-create a VPC Lattice ServiceNetwork when a Gateway is reconciled, eliminating the need for users to pre-create ServiceNetworks or rely on DEFAULT_SERVICE_NETWORK.

Changes

Auto-create ServiceNetwork (gateway_controller.go)

• reconcileUpsert calls snManager.CreateOrUpdate() using the Gateway .metadata.name as the SN name
• CreateOrUpdate is idempotent — finds and reuses an existing SN if one already exists
• Ownership tracked via ManagedBy tag; externally-created SNs are never deleted by the controller

Sibling Gateway deletion safety (gateway_controller.go)

• reconcileDelete checks for sibling Gateways (same .Name, different namespace) before deleting the SN
• If another active Lattice-controlled Gateway shares the SN name, deletion is skipped
• Gateways with DeletionTimestamp set are excluded from the sibling check, so simultaneous deletion of all siblings still cleans up the SN

Service association delete guard (service_network_manager.go)

• Delete() checks for active service associations before attempting SN deletion
• Returns a clear error: "cannot delete ServiceNetwork X: N service association(s) still active, detach all services before deleting the Gateway"

Documentation (docs/api-types/gateway.md)

• Documents auto-creation behavior and default settings (no auth, no sharing config)
• Documents external SN reuse for advanced configuration
• Documents deletion behavior and safety guards

Fixes #888

Testing

Unit tests

• TestHasSiblingGateway: 4 cases — no sibling, has sibling (same name different ns), sibling being deleted (not counted), different name (not a sibling)
• Test_Delete_SnOwned_ActiveServiceAssociations: verifies Delete returns error when SN has active service associations
• All existing tests pass (go test ./...)

E2E integration tests (gateway_service_network_test.go)

• Sibling Gateway deletion safety: creates two Gateways with the same name in different namespaces, verifies deleting one does not remove the SN, verifies deleting the last one does
• Service association delete guard: creates a Gateway, manually associates a dummy Lattice service to its SN, verifies Gateway deletion is blocked (finalizer not removed), verifies Gateway deletes after removing the association
• All 4 specs pass against a live EKS cluster with VPC Lattice

[SinghVikram97]

One of the e2e test in failing

Test vpc association policy Update a VpcAssociationPolicy with associateWithVpc to false, expecting deleted ServiceNetworkVpcAssociation [Serial]

There is a CRD: https://www.gateway-api-controller.eks.aws.dev/latest/api-types/vpc-association-policy/ if you set associateWithVpc flag as false it should delete SNVA, but after this change it creates one if it doesn't exist.

Need further consideration on how to handle this case before we merge this.