feat: persist progress visibility after modal dismissal

[lobinuxsoft]

Summary

Addresses lobinuxsoft/capydeploy#230: when the user dismissed the transfer progress modal, there was no way to bring it back — they had to wait for the transfer to finish without any feedback.

Approach

Most of the infrastructure was already in place (progressState singleton with subscribers, ProgressModalContent modal, background poller that survives the QAM panel unmount). What was missing was the trigger to resurface the modal once the user navigated away from it.

Instead of adding a dedicated "resume" button (which still requires the user to remember to go look for it), the progress comes to the user via a persistent Decky toast.

Changes

• ProgressModalContent now accepts an onUserDismiss callback so the poller can distinguish manual dismisses (X / Esc / back) from programmatic Close() calls.
• When the user dismisses the modal while a transfer is still active, a long-lived recovery toast is emitted (10s popup, 24h tray expiration). Tapping the toast reopens the modal via showModal().
• The toast auto-dismisses when the modal is reopened, when the operation completes/errors, or when the programmatic close fires.
• A closingModalProgrammatically guard prevents our own Close() calls from triggering the recovery toast path.

Test plan

• ./build.sh produces a working ZIP
• Installed on OneXFly (F1 Pro, Bazzite gaming mode)
• Transfer from Hub → modal opens automatically
• Manual dismiss (X / Esc) → recovery toast appears with mascot
• Tap toast → modal reopens, progress continues updating live
• Second dismiss + tap cycle works
• On complete event → recovery toast disappears, success toast appears
• Behavior with simultaneous transfers (single toast assumed — untested edge case)