fix(apisix): match service key to container_name for stable Swarm DNS

[wax911]

Closes #503.

Changes the APISIX gateway service key from apisix_gateway (underscore) to apisix-gateway (hyphen) to match the existing container_name. The generator strips container_name from Swarm stacks, so the service key becomes the DNS-resolvable name on the shared traefik-public overlay network.

This preserves DNS stability: apisix-gateway:9091 resolves as the Prometheus scrape target in both Swarm and non-Swarm modes, avoiding the need to change configuration files for each deployment mode.

Changes:

• apisix/api-gateway/docker-compose.yml: service key apisix_gateway → apisix-gateway
• apisix/api-gateway/swarm.fragment.yml: matching key change
• stacks/infrastructure.yml: regenerated

[wax911]

This does not fully satisfy #503 as written.

Changing the service key from apisix_gateway to apisix-gateway preserves the old short name in the source Compose file, but it does not prove that apisix-gateway:9091 is resolvable from the observability stack after Swarm deployment. Docker stack deploy creates stack-scoped service names, and Docker's own examples show service names such as vossibility_nsqd after deployment: https://docs.docker.com/reference/cli/docker/stack/deploy/

The safer fixes are one of:

1. Keep the existing service key and change Prometheus to the actual fully-qualified Swarm service name, e.g. infrastructure_apisix_gateway:9091.
2. Add an explicit network alias for apisix-gateway on the shared traefik-public network and document that alias as the stable cross-stack scrape name.

The #505 handoff/deepwork note also records the aligned direction for #503 as a fully-qualified cross-stack target, not service-key renaming. This PR should either update the Prometheus target directly or add a deliberate alias with runtime validation evidence.