docs(examples/server): add health-check trap when switching to background load

[NazarKozak]

What does this PR do?

Adds a "Production deployment notes" section to examples/server/README.md covering one of the easier traps to fall into when adapting the example for orchestrated production environments (Kubernetes, Cloud Run, Vertex AI, AWS Fargate).

Why

The shipped examples/server/server.py loads the pipeline synchronously at module import, before uvicorn.run(...) binds the HTTP port. That is the safe default — the orchestrator's readiness probe naturally fails (connection refused) until the model is on GPU. No health-check work is required.

The trouble starts when users adapt the example for cold-start–sensitive deployments of large pipelines (SD3, FLUX.2, etc.) where the orchestrator's startup probe times out before from_pretrained returns. The natural fix is to spawn the load on a background thread and bind the port immediately, which moves the readiness signal to /health. At that point a route like return {"status": "ok"} will return 200 OK from the moment the process starts, the orchestrator marks the replica ready, and traffic gets routed to a replica that hasn't loaded the model yet — every request returns 5xx until the background load finishes. If the load crashes, the replica keeps returning 200 indefinitely.

This bug is easy to hit and silent in logs (the orchestrator is happy; only end-user requests fail).

Changes

• New ## Production deployment notes section in examples/server/README.md with two subsections:
  • Synchronous load is the safe pattern — what server.py already does and why it works for free under most orchestrators.
  • Background-loading variant — and the health-check trap — when you'd switch and the minimal /health pattern that returns 503 while loading or on load error, 200 only when the pipe is ready.
• Includes a ~25-line FastAPI snippet that uses threading.Thread from @app.on_event("startup"), which mirrors what serverasync.py already does at startup but adds the gated /health route.

Behavioral change

None — docs only. No code changes. No new dependencies.

Fixes # (no related issue — surfaced repeatedly across orchestrated deployments)

Before submitting

• This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
• Did you read the contributor guideline?
• Did you read our philosophy doc (important for complex PRs)?
• Was this discussed/approved via a GitHub issue or the forum? Please add a link to it if that's the case.
• Did you make sure to update the documentation with your changes?
• Did you write any new necessary tests? (N/A — docs only)

Who can review?

Docs: @stevhliu @sayakpaul