Failed warning health check when not using Kibana

**Describe the bug**
When Kibana is not installed/used, GeoNetwork’s warning health check endpoint (`/catalogue/warninghealthcheck`) returns HTTP `500` due to `DashboardAppHealthCheck`. This creates repeated error logs and can trigger false monitoring alarms.

There are two related problem cases:
1. **Default config** (`kb.url` resolves to `http://localhost:5601`): health check fails with connection refused.
```
{
"name": "DashboardAppHealthCheck",
"status": "ERROR",
"msg": "Connect to localhost:5601 [localhost/127.0.0.1, localhost/0:0:0:0:0:0:0:1] failed: Connection refused (Connection refused)",
"exception": "org.apache.http.conn.HttpHostConnectException: Connect to localhost:5601 [localhost/127.0.0.1, localhost/0:0:0:0:0:0:0:1] failed: Connection refused (Connection refused)"
}
```
2. **Intentional disable attempt** (`kb.url` set to empty string `""`): health check still reports `ERROR` (`Dashboard application is not configured...`) and endpoint still returns HTTP `500`.
```
{
"name": "DashboardAppHealthCheck",
"status": "ERROR",
"msg": "Dashboard application is not configured. Update config.properties to setup Kibana to use this feature."
}
```

So even when Kibana is intentionally disabled by configuration, warning health check still fails as an error.

**To Reproduce**
Steps to reproduce the behavior:
1. Start GeoNetwork without Kibana running.
2. Go to `https:///catalogue/warninghealthcheck`.
3. Observe HTTP `500` and error details like connection refused to localhost:5601.
4. Set `kb.url` to empty string `""` in config.
5. Restart GeoNetwork.
6. Go again to `https:///catalogue/warninghealthcheck`.
7. Observe it still returns an error (HTTP `500`) with message indicating dashboard app is not configured.

**Expected behavior**
If Kibana is intentionally disabled via configuration (inferred from empty/missing `kb.url`), this should not be treated as a failing warning health check.
- `/catalogue/warninghealthcheck` should return HTTP `200` in this case.
- `DashboardAppHealthCheck` should be skipped, marked as disabled, or reported as non-failing informational status.
- Monitoring should not raise false alarms for an intentionally disabled optional component.