fix(gui): fix progress accounting and cancellation on window close

[Guts]

Description

Three defects around the progress bar and the cancel button, grouped as agreed.

1. The progress bar reached 100% halfway through a run

read_dataset() and export_metadataset() each incremented the counter on success, so a queue of N datasets stepped it up to 2N — while the GUI sets the bar's maximum to count_files_to_process(), i.e. N. Symmetrically, a dataset that failed to read (or was already marked processed) incremented nothing at all, so a run holding failures could end short of the maximum.

Fixed by counting datasets rather than phases: exactly one step per dataset, taken in process_datasets_in_queue() whatever the outcome. The per-phase messages ("Reading …", "Exporting …") stay — they are what makes the status line useful.

This is the one change outside mw_dicogis.py: the increments live in the pipeline, so that is where the accounting had to be fixed. The CLI passes progress_reporter=None and is unaffected.

2. Closing the window during a run froze it, then leaked the thread

closeEvent() only called QThread.quit(), which asks a thread's event loop to return — something a worker blocked inside its own run() never reaches. Closing during a scan or an analysis blocked the window for the full three-second wait() and still left the thread running. It now requests cancellation first, which the workers already poll, then waits.

3. The cancel button stayed visible after a successful PostGIS run

Each terminal handler hid the button on its own, and _on_db_processing_finished had been forgotten. Hiding it in _enable_processing_controls() — which every path out of a run already goes through — fixes it by construction rather than one handler at a time, so the redundant calls are dropped.

Tests

Five added or reworked. On the previous code:

Test	Symptom before
test_progress_advances_once_per_successful_dataset	counter at 6 for 3 datasets
test_progress_reporter_receives_messages_but_no_increment	Expected 'increment' to not have been called. Called 1 times.
test_main_window_close_requests_cancellation	assert False is True where False = is_canceled()
test_main_window_hides_cancel_button_when_a_run_ends	assert True is False where True = btn_cancel.isEnabled()

test_progress_advances_once_per_dataset_whatever_the_outcome pins the new behaviour for unreadable and already-processed datasets; it is a behaviour pin, not a regression guard — I first wrote the mixed queue as the regression test and it passed on the old code, its 2 successes × 2 increments plus 2 failures × 0 happening to total the same 4. Hence the split.

Two notes

How this was verified. These modules import osgeo, which will not build in my sandbox, so the runs above used a locally-injected fake osgeo (a scratch file, not committed). Under it the whole suite reports the same 27 failures on this branch as on master — the georeader tests, which need real GDAL — with 285 passing here against 280 there. CI against real GDAL remains the real check.

Lint. ruff check goes from 38 to 49 violations on the four touched files: +11 S101/ANN001 from the tests added to tests/ui/test_main_window_smoke.py. Nothing new in kind — every existing test in that file carries them — because [tool.ruff.lint.per-file-ignores] keys them on "tests/test_*.py", which does not match the tests/ui/ subfolder. Changing that pattern to "tests/**/test_*.py" would zero them out repo-wide, but that is a tooling change and this is a bugfix PR, so I have left it alone. Happy to send it separately.

Related issue(s)

None — found while reviewing the code ahead of the 4.0.0-beta13 release.

Type of change

• Bug fix (fix/… branch)
• New feature or enhancement (feature/… branch)
• Documentation (docs/… branch or *.md/docs/** changes)
• Packaging / build (packaging/… branch or builder/** changes)
• Tooling / CI-CD (tooling/… branch or .github/** changes)
• Tests only (tests/** changes)

Checklist

• I have read the Contributing Guidelines
• pre-commit run --all-files passes locally — its two ruff hooks, run as configured on the changed files: ruff-format reports them already formatted and ruff check --fix-only rewrites nothing. See the lint note above for what ruff check still reports
• I have added or updated tests covering my changes
• I have updated the documentation where relevant — none needed, no doc page describes the progress bar's scale
• pytest passes locally — 221 passed on the plain non-GDAL modules, with the same 8 pre-existing sandbox failures as on master; the GDAL-importing modules were run under the fake osgeo described above

AI/LLM disclosure

• Level: 7 — human specced, bots coded
• Model: claude-opus-5
• Session: https://claude.ai/code/session_01WABM4NMiD2DhEVreKLxWLq

🤖 Generated with Claude Code

https://claude.ai/code/session_01WABM4NMiD2DhEVreKLxWLq

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.09%. Comparing base (d79b4dd) to head (641511b).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #498      +/-   ##
==========================================
+ Coverage   75.54%   76.09%   +0.55%     
==========================================
  Files          46       46              
  Lines        3410     3409       -1     
  Branches      414      415       +1     
==========================================
+ Hits         2576     2594      +18     
+ Misses        713      695      -18     
+ Partials      121      120       -1     

Flag	Coverage Δ
unittests	76.03% <100.00%> (+0.55%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
dicogis/georeaders/process_files.py	78.68% <100.00%> (+0.39%)	⬆️
dicogis/ui/mw_dicogis.py	59.39% <100.00%> (+3.88%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.