Error in timezone handling GHC Runner

**Describe the bug**
The APScheduler suddenly gives errors.

**To Reproduce**
Steps to reproduce the behavior, e.g.:

1. add a Resource, e.g. WMS
2. Wait for execution
3. See error (see below)

**Expected Behavior**
No error.

**Screenshots or Logfiles**
```
2026-06-26 18:11:28,225 - apscheduler.executors.default - ERROR - Job "run_job (trigger: interval[0:30:00], next run at: 2026-06-26 18:41:28 CEST)" raised an exception
Traceback (most recent call last):
File "/GeoHealthCheck/lib/python3.12/site-packages/apscheduler/executors/base.py", line 131, in run_job
retval = job.func(*job.args, **job.kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/GeoHealthCheck/GeoHealthCheck/scheduler.py", line 119, in run_job
if not lock.obtain(uuid, frequency):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/GeoHealthCheck/GeoHealthCheck/models.py", line 693, in obtain
if not self.has_expired():
^^^^^^^^^^^^^^^^^^
File "/GeoHealthCheck/GeoHealthCheck/models.py", line 690, in has_expired
return now > self.end_time
^^^^^^^^^^^^^^^^^^^
TypeError: can't compare offset-naive and offset-aware datetimes
2026-06-26 18:11:28,228 - __main__ - ERROR - error_listener: EVENT_JOB_MISSED -
```
**Context (please complete the following information):**
- OS: any
- Browser NA
- Browser Version NA
- Python Version 3.12
- GeoHealthCheck Version master on June 26, 2026

If running with Docker:
- Docker installed version
- GeoHealthCheck Docker Image version : latest

**Analysis
I suspect this happens since `tzlocal` upgrade to latest version related to APScheduler. The previous was `tzlocal<3.0`
Now:
```
tzdata 2025c hc9c84f9_1 conda-forge
tzlocal 5.4.3 pypi_0 pypi
```
See https://github.com/YelpArchive/elastalert/issues/2968

Plus seems to happen only on existing databases, i.e. jobs stored.
Suspect difference/mismatch between: *"Offset-naive and Offset-aware datetimes"*.
Newly added jobs work ok, like this local instance:

```
2026-06-26 19:21:18,133 - apscheduler.executors.default - INFO - Running job "run_job (trigger: interval[0:10:00], next run at: 2026-06-26 19:31:18 CEST)" (scheduled at 2026-06-26 19:21:18.127902+02:00)
2026-06-26 19:21:18,139 - scheduler - INFO - 1 No Lock at all: obtain new
2026-06-26 19:21:18,155 - GeoHealthCheck.probe - INFO - Requesting: GET url=https://service.pdok.nl/kadaster/adressen/wms/v1_0
2026-06-26 19:21:18,162 - urllib3.connectionpool - DEBUG - Starting new HTTPS connection (1): service.pdok.nl:443
2026-06-26 19:21:18,257 - urllib3.connectionpool - DEBUG - https://service.pdok.nl:443 "GET /kadaster/adressen/wms/v1_0?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetCapabilities HTTP/1.1" 200 9391
2026-06-26 19:21:18,257 - GeoHealthCheck.probe - INFO - response: status=200
2026-06-26 19:21:18,258 - GeoHealthCheck.probe - INFO - Check: fun=GeoHealthCheck.plugins.check.checks.HttpStatusNoError result=True
2026-06-26 19:21:18,258 - GeoHealthCheck.probe - INFO - Check: fun=GeoHealthCheck.plugins.check.checks.XmlParse result=True
2026-06-26 19:21:18,258 - GeoHealthCheck.probe - INFO - Check: fun=GeoHealthCheck.plugins.check.checks.NotContainsOwsException result=True
2026-06-26 19:21:18,258 - GeoHealthCheck.probe - INFO - Check: fun=GeoHealthCheck.plugins.check.checks.ContainsStrings result=True
2026-06-26 19:21:18,258 - GeoHealthCheck.probe - INFO - Result: success=True msg=OK response_time=0.103404
2026-06-26 19:21:18,262 - scheduler - INFO - 1 run_resource OK
```

Start by reproducing the failure with an existing database, then inspect GeoHealthCheck/models.py around has_expired() and obtain(), followed by GeoHealthCheck/scheduler.py around run_job(). Done means existing stored jobs no longer raise the offset-naive/offset-aware TypeError and newly added jobs continue to execute.

Written by the indexing model from the issue text.