FIX: Tighten CLI backend health-check validation

[romanlutz]

Description

The CLI's backend readiness probe (PyRITApiClient.health_check_async) previously treated any HTTP 200 from /api/health as "backend ready." That check is too loose: an unrelated process listening on the same host/port can return 200 and be mistaken for a live PyRIT backend, so the CLI could happily proceed against the wrong server.

This tightens the probe to confirm the responder's identity, not just its status code. After verifying the response is 200, it parses the JSON payload and requires both status == "healthy" and service == "pyrit-backend" before reporting the backend as ready. A non-200 response, or a 200 from any other service (mismatched or missing fields), now correctly reports "not ready." Connection errors continue to be handled as before.

Tests and Documentation

Tests: tests/unit/cli/test_api_client.py

• test_health_check_returns_true_on_200 now returns the identifying payload (status/service) so the stricter check passes.
• New test_health_check_returns_false_for_unrelated_service asserts a 200 from a different service ({"status": "ok", "service": "another-service"}) is rejected.
• test_health_check_returns_false_on_non_200 is unchanged.
• uv run pytest tests/unit/cli/test_api_client.py -q -> 30 passed.

Documentation: No doc or notebook changes; this is a client-side behavior fix covered by the unit tests above. I also ran uv run jupytext --execute --to notebook doc/scanner/1_pyrit_scan.py and saw no regression attributable to this change.