Log hosted-check retries without exposing request data

[kstonekuan]

The hosted Build AI path classifies retryable failures and computes bounded delays in src/hflow/build_ai_vlm_checks.py:139, then retries through Tenacity at src/hflow/build_ai_vlm_checks.py:863. A slow call currently gives no indication that HFlow is waiting before another attempt.

Add one INFO record when a retry is scheduled. Include the next attempt number, bounded delay, and a safe failure category such as the HTTP status or transport failure. Do not log the image, request or response body, authorization data, headers, query string, API key environment variable, or full endpoint URL.

Follow the module-level logger pattern in src/hflow/app.py:106. Extend the hosted-response scenarios in tests/test_build_ai_vlm_checks.py that already exercise transient failures and retry budgets.

Definition of done:

• First-attempt success emits no retry record.
• Each scheduled retry emits exactly one INFO record.
• HTTP and transport failures produce useful categories without sensitive request data.
• Exhausted retries preserve the existing exception type and message.
• Tests cover recovery after a transient failure, retry exhaustion, record count, and absence of a unique secret sentinel from every emitted message.
• Run uv run ruff check --fix, uv run ruff format, uv run ty check, and uv run pytest -q.

[J-Varela]

I'd like to work on this. I'll follow the existing module-level logger pattern, add one INFO record per scheduled retry with the attempt number, bounded delay, and safe failure category, and extend the existing hosted-response tests while ensuring no request or sensitive data is logged.