Bug Report: APISIX Standalone API-driven Mode Workers Not Ready on Startup

Environment
- APISIX Helm Chart Version: 2.11.1
- Deployment Mode: Standalone API-driven mode
- Platform: Kubernetes with Helm Chart
- Components: Apisix + Apisix Ingress Controller

helm install apisix \
--namespace ingress-apisix \
--create-namespace \
--set service.type=NodePort \
--set apisix.deployment.role=traditional \
--set apisix.deployment.role_traditional.config_provider=yaml \
--set etcd.enabled=false \
--set ingress-controller.enabled=true \
--set ingress-controller.config.provider.type=apisix-standalone \
--set ingress-controller.apisix.adminSerivce.namespace=ingress-apisix \
--set ingress-controller.gatewayProxy.createDefault=true \
charts/apisix

Problem Description
When deploying APISIX in standalone API-driven mode with ingress-controller, APISIX pods fail readiness checks with the error:
`[lua] init.lua:925: status_ready(): worker id: 7 has not received configuration, client: `

Cause Analysis
1. APISIX startup: Workers initialize with status = false (no configuration received)
2. Readiness probe: /apisix/status/ready returns 503 because workers have no config
3. Pod marked NotReady: Kubernetes service excludes the pod from traffic routing
4. ingress-controller startup: Cannot reach APISIX admin API (service has no ready endpoints)
5. Deadlock: ingress-controller can't sync initial config, APISIX workers never become ready

Start by reproducing the provided Helm installation in Kubernetes and inspect the /apisix/status/ready readiness response alongside the ingress-controller startup. Trace how standalone API-driven mode supplies the initial configuration and how the APISIX admin service is reached. Done means APISIX workers become ready and the ingress-controller can sync its initial configuration without the readiness deadlock.

Written by the indexing model from the issue text.