docs: use the readiness endpoint on the cloud deployment pages and name the pool, storage and sign-up behaviors

[silentoplayz]

Summary

I compared the Kubernetes, ECS, Azure Container Apps and Cloud Run pages with the health endpoints and the storage and pool code.

• Readiness: the pages probed /health/db, which only pings the database and can answer HTTP 200 before startup (migrations, config seeding, admin creation) has finished. They now use /ready. It waits for startup and also pings Redis.
• Azure: AZURE_STORAGE_KEY is optional. Without it, the blob client uses DefaultAzureCredential, so a managed identity with a Blob data role works.
• Sign-up: creating the admin from WEBUI_ADMIN_EMAIL and WEBUI_ADMIN_PASSWORD turns open sign-up off automatically, and the verification step now says so.
• Connection budgeting now names DATABASE_POOL_SIZE, DATABASE_POOL_MAX_OVERFLOW and PGVECTOR_POOL_SIZE, and the ingress notes name /ws/socket.io/.

Related issue or discussion

None.

Checklist

• I have reviewed the relevant documentation and matched the existing style.
• This PR meets Open WebUI's contribution standards: it is accurate, relevant to users, narrowly scoped, maintainable, and not promotional content, advertising, lead generation, SEO placement, or a request to list a product, service, provider, integration, gateway, tool, or company primarily for visibility.
• I understand that PRs that do not meet these standards may be closed without review and will not be merged. Repeated, low-quality, off-topic, promotional, or intentionally misleading submissions may result in the contributor being blocked from future participation in Open WebUI repositories.

Notes for reviewers

Sources on dev: main.py (/ready, /health/db, the env-admin creation that sets ui.enable_signup to false, the /ws mount), storage/provider.py (Azure credential fallback), env.py (DATABASE_POOL_*), and config.py (PGVECTOR_POOL_*).