READ-ONLY INVESTIGATION. Do NOT modify any files. Do NOT commit. Do NOT push.

Environment: Windows 11, bash shell. Project root: J:\CLAUDE\PROJECTS\Wakeword.

PROBLEM
There are TWO databases in play and they appear out of sync:

1. **Postgres `training_jobs` table** — currently EMPTY (0 rows). Earlier in today's session, when I polled `/api/training/status/{id}`, the API returned status data for jobs (e.g. progress=27.0) — implying it reads from this table. Now empty.

2. **SQLite `/app/data/job_queue.db` `jobs` table** — has 49 rows: 17 completed, 25 failed, 7 cancelled. Job 49 shows status='failed' with a real error about ONNX export.

The /api/training/status/{id} endpoint, when polled today after job 49 was created, returned "queued progress=0.0" for 15 minutes — never showing the failure that's recorded in SQLite. Either:
- The endpoint reads from Postgres (which is empty → 0 rows → falls back to default "queued"?)
- The endpoint reads from SQLite (which has the right answer → why was it returning "queued progress=0.0"?)

Find the truth.

INVESTIGATE THOROUGHLY (read-only)

1. Read `console/backend/app/routes/training.py` (or wherever /api/training/status/{id} is defined). What table does it query?
2. Read `console/backend/app/job_queue.py` — what DB does the worker write progress to?
3. Read `console/backend/alembic/versions/` — list every migration in order. Does any one DROP, RECREATE, TRUNCATE, or otherwise wipe `training_jobs`?
4. Read `console/backend/app/models.py` — is `training_jobs` mapped to Postgres? Is `jobs` table mapped anywhere?
5. Read `console/backend/app/services/training_service.py` — when training_service.run_training_job_sync runs, what does it write back to Postgres? Does it create/update a TrainingJob row?

Then directly query the Postgres DB to triangulate:
6. `docker exec wakeword-postgres-1 psql -U violawake -d violawake -c "SELECT count(*) FROM trained_models"` — Are there any trained models from past successful jobs?
7. `docker exec wakeword-postgres-1 psql -U violawake -d violawake -c "\dt"` — list all tables.
8. `docker exec wakeword-postgres-1 psql -U violawake -d violawake -c "SELECT version_num FROM alembic_version"` — current migration head.
9. Check the SQLite job_queue.db for the schema and how it correlates to Postgres training_jobs (might have a `pg_job_id` field?):
   ```bash
   docker exec wakeword-backend-1 python -c "
   import sqlite3
   c = sqlite3.connect('/app/data/job_queue.db')
   for r in c.execute('PRAGMA table_info(jobs)'):
       print(r)
   "
   ```
10. Look at git history for `training.py` and `job_queue.py` since today's session start (commits since `54f20b4`). Did any of my commits change the routing or DB?

Report:
- Which DB is the source of truth for training job status as far as the API is concerned.
- Why Postgres `training_jobs` is empty (was it wiped, or never populated?).
- Whether /api/training/status returning "queued" while SQLite has "failed" is a known inconsistency or a real bug.
- A concrete one-paragraph "this is the real situation" verdict.

CRITICAL CONSTRAINT: read-only. Do NOT modify files, commit, or restart anything.
