fix: don't resume Immich jobs on finish if they were never paused

[hugodantas]

`finishing()` calls `resumeJobs()` unconditionally at the end of every upload run, regardless of whether `pauseJobs()` actually ran. `pauseJobs()` is gated behind `--pause-immich-jobs` (default `true`), but the matching `resumeJobs()` call wasn't gated the same way.

This causes two problems when running with `--pause-immich-jobs=false`:

• `resumeJobs()` requires the `job.create` API key permission, which a run that never touched job state shouldn't need.
• If that call fails (e.g. the key genuinely lacks `job.create`), `finishing()` returns early and `GenerateReport()` never runs — so the run silently ends with no Asset Tracking Report at all, even though the upload itself completed successfully.

This fix gates `resumeJobs()` behind the same `uc.client.PauseImmichBackgroundJobs` flag that already gates `pauseJobs()`, so a run that never paused jobs never tries to resume them.

Testing

`go build`, `go vet ./...`, and `go test ./...` all pass (note: `app/upload` has no existing test files, so this doesn't add regression coverage for the fix itself — just confirms nothing else broke).

Reproduced against a live v0.32.0 Immich server by running `upload from-google-photos --pause-immich-jobs=false` with an API key scoped only for uploads (no `job.create`): before the fix, the run completed the upload but exited with a `job.create` permission error and no report; after, it completes cleanly with the report generated.

[gthb]

Related: #1425 addresses the same case (no resume when --pause-immich-jobs=false, so no job.create requirement and the report is still generated), and additionally leaves alone queues that were paused by hand before the run (it reads GET /api/jobs first and records only the queues it pauses itself), resumes queues paused so far when pausing fails partway, and adds unit tests. Same root cause as #1290. Both PRs change the same lines in finishing(), so whichever is merged first, the other will need a trivial conflict resolution. (I didn't notice this one until just as I was posting that one!)

[gthb]

Both PRs change the same lines in finishing(), so whichever is merged first, the other will need a trivial conflict resolution.

More precisely: if #1425 is merged first, this PR's change is fully contained in it and I think this can be closed. The conflict resolution is only needed if this one goes in first.