[gmmcosta15]

Description

• Feature
• Bug Fix
• Code Refactor
• Documentation

Cancelling a print could leave the UI stuck behind the "Cancelling print" loadscreen. The loadscreen was dropped only on print_stats standby, which is never reached after a cancel until the next job or a manual action.

Changes

• PrintTab tracks a pending cancel (_cancel_pending) and drops the loadscreen once both conditions hold:
  • print_stats.state is cancelled
  • idle_timeout.state is no longer Printing
• print_stats turns cancelled partway through the CANCEL_PRINT macro, but idle_timeout stays Printing while the gcode mutex is held and moves are queued. Waiting for both keeps the loadscreen up until the macro and its moves have finished.
• A Klippy shutdown or E-stop while the cancel is pending also drops the loadscreen, because print_stats never reaches cancelled in that case.
• Only a cancel started from this screen is tracked. Standby handling (unblocking tabs, saving the Z offset snapshot) is unchanged.

Tests

• Unit tests: the loadscreen waits for the cancel macro to finish, a cancel from another client leaves it alone, a shutdown during the cancel clears it, and the cancel page no longer touches it.