OperationalError: unable to open database file

[gisce-ti-sentry]

Sentry Issue: GAB-9

OperationalError: unable to open database file
  File "threading.py", line 1024, in run
    self._target(*self._args, **self._kwargs)
  File "github_agent_bridge/executor.py", line 186, in _loop
    while not self.stop_event.is_set():
  File "github_agent_bridge/executor.py", line 58, in work_one
    worker_id = worker_id or f"worker-{uuid.uuid4().hex[:8]}"
  File "github_agent_bridge/queue.py", line 148, in claim_next
    with self.connect() as con:
  File "github_agent_bridge/queue.py", line 36, in connect
    con = sqlite3.connect(self.path, timeout=30, isolation_level=None)

This issue was automatically created by Sentry via Github Issue

[giscebot]

Fix proposed in #19.

The worker now recreates the SQLite parent directory before each connection (instead of only during JobQueue construction), and expands literal ~ paths. This covers the reported claim_next() failure when a long-running process outlives a removed state directory.

Validation: focused queue suite passes (16 tests), and the full suite passes in a clean Python 3.11 test environment.

Traceability blocker: no TASK id was provided and this runtime has no ERP URL/database/token configuration, so I could not create the project 9459 task.

[giscebot]

Maintainer verification completed for #19.

• clean Python 3.11 environment: full suite passes (158 passed)
• regression proof: reverting only the production fix makes both new tests fail, including sqlite3.OperationalError: unable to open database file; restoring the fix makes both pass
• branch is up to date with main, the worktree is clean, and GitHub reports the PR as mergeable

The traceability blocker remains: this runtime has no ERP connection configuration, so it cannot create the required task in project 9459 without inventing credentials or a TASK id.