refactor: improve work manager for app installation and update

Description

This change moves normal install scheduling to a database-driven queue, uses one unique work name per package to avoid duplicate jobs, and adds startup cleanup for stale install states.

It also marks enqueue failures as installation issues so apps do not stay forever in queued/installing state.

The updates screen was adjusted to detect both the new and old install work patterns (tag vs. unique ID).

Technical details

Used setExpedited()

• Expedited work is best suited for short tasks which need to start immediately and are important to the user or user-initiated.
• WorkManager provides an additional signal to the OS that this work is important.
• Battery Saver and Doze, are less likely to affect expedited work.
• https://developer.android.com/develop/background-work/background-tasks/persistent/getting-started/define-work#expedited

Added constraints for

• Network check and
• Low storage check

Ensured uniqueness for installation per-package

• Ensured unique work based on per-package
• https://developer.android.com/develop/background-work/background-tasks/persistent/how-to/manage-work#unique-work

Finer control on download and installation

• Moved away from WorkManager's internal chain of work to custom control
• Decision on when to trigger download and install work now based on the database's AWAITING status, processed one by one
• On app startup, WorkManager and database reconcile their status to prune any failed downloads

Introduction of InstallHelper class

• Tied with Application lifecycle, so can supervise download and install work off the UI
• The injected scope is a SupervisorJob + Dispatchers.IO, so child coroutines can run and fail independently

Tests

Issues

https://gitlab.e.foundation/e/os/backlog/-/issues/4125

10 commandments of code review

👪 ❤️ code review guidelines