[Bug]: Critical! Health check response-ms includes full HTTP roundtrip, not just query time

Personne n'a encore pris cette issue.

The `response-ms` value in health check results measures the full self-HTTP-call duration (HTTP client → middleware → auth → routing → controller → DB → response), not just the database query execution time.

## Expected

`response-ms` should ideally represent the actual database query or endpoint processing time, making it useful for monitoring database health.

## Actual

The health check implementation (`HealthCheckHelper`) makes real HTTP calls to `GET /api/{entity}?$first=N` and `POST /graphql`. The `response-ms` measures the complete round-trip through:

1. HTTP client overhead
2. Kestrel request processing
3. Authentication middleware
4. Routing middleware
5. Controller action
6. SQL query execution
7. JSON serialization
8. Response delivery

Evidence from DAB logs:
```
Start processing HTTP request GET http://localhost:5000/api/Todo?$first=50
Sending HTTP request GET http://localhost:5000/api/Todo?$first=50
...
Received HTTP response headers after 155.4462ms - 200
```

A simple `SELECT TOP 51` query takes <5ms in the database, but the health check reports 155ms+ because it includes the full middleware pipeline. On cold starts (first health check after startup), this can be 500-700ms+.

Commencez par localiser HealthCheckHelper et suivre la manière dont il mesure le temps des appels GET /api/{entity}?$first=N et POST /graphql. Comparez la valeur response-ms rapportée avec le temps de traitement de la base de données ou de l’endpoint ; le travail est terminé lorsque la métrique exclut l’aller-retour HTTP et middleware complet et est couverte par des tests appropriés.

Rédigé par le modèle d'indexation à partir du texte de l'issue.