Consolidate DownloadCenter operation state into one attempt model

[thsnkhn]

Objective

Replace the scattered operation state in DownloadCenter with one per-download attempt model.

Complete #65 first. Prefer completing #67 and #68 before finalizing this model so it represents the simplified recovery architecture.

Current problem

DownloadCenter maintains many task dictionaries, pending-ID sets, retry maps, pause-result maps, cancellation maps, cleanup maps, and backend-specific attempt identifiers. A single download operation can be represented in several collections at the same time.

This makes pause, retry, cancellation, shutdown, and stale callback handling difficult to reason about.

Proposed design

Introduce one dictionary:

[UUID: DownloadAttempt]

Each attempt should contain only the state needed by its backend:

• attempt identifier
• backend
• phase
• active task, process, or aria2 GID reference
• pending user intent
• recovery reference
• retry information when applicable

Use an explicit phase model such as:

• preparing
• active
• pausing
• cancelling
• completing
• terminal

Move backend-specific transitions behind focused helpers. Remove collections that duplicate the attempt phase or durable DownloadItem fields.

Safeguards to retain

• Attempt identifiers for stale callbacks.
• One active writer per download.
• Normal queue-slot accounting.
• Pause, cancel, retry, removal, and shutdown coordination.
• Backend-specific recovery references.
• Serialized durable record mutations.

Acceptance criteria

• One canonical in-memory operation state exists per download.
• Contradictory combinations of pending sets and task dictionaries are not representable.
• Backend event handlers verify the current attempt identifier.
• Normal direct, browser, media, and torrent workflows remain unchanged.
• DownloadCenter becomes materially smaller and easier to split by backend.
• Target a further reduction of approximately 500 to 1,000 production lines.
• Lifecycle and startup recovery tests pass.