bug(backups): active restore can race post-add category update

[ultronknowhere]

Summary

An incremental restore with startPaused=false can report a set_category error immediately after qBittorrent accepts the torrent.

Observed while validating #2258 against qBittorrent v5.2.2 on current develop (2a61f00 base plus the PR commit). This appears separate from the save-path change: restore already passes category in the initial AddTorrent options, then immediately calls SetCategory for the same hash.

Reproduction

1. Create a qB category with save path /downloads/restore-extension.
2. Add a trackerless torrent in that category and snapshot it.
3. Delete only the torrent object while retaining its payload.
4. Execute incremental restore with:

{
  "mode": "incremental",
  "startPaused": false,
  "skipHashCheck": false,
  "autoResumeVerified": false
}

Observed

The restore response reports:

{
  "errors": [
    {
      "operation": "set_category",
      "message": "no valid torrents found to set category"
    }
  ]
}

Direct qB read-back after settlement showed that the torrent was successfully added and became complete (stalledUP, progress 1.0) with the expected category, tag, save path, and content path. The test torrent was trackerless and the disposable Docker network had no external egress.

Expected

A successful add should not produce a restore error merely because qB has not exposed the new hash to the immediate follow-up category mutation yet.

Likely boundary

applyTorrentPlan passes category and tags in the AddTorrent options, then immediately calls SetCategory and SetTags for the same new hash. Possible approaches:

• avoid redundant post-add mutations when the add options already supplied those values; or
• use a small bounded retry after add until qB exposes the hash before applying post-add metadata.

This should remain separate from #2258 so the category-derived save-path fix stays minimal.