fix: cancellation defeats the cache-persisting finally blocks in BulkPackageUpdater

[credfeto]

Found by AI full-repo code analysis (bugs and performance sweep of non-test projects).

Problem

src/Credfeto.DotNet.Repo.Tools.Packages/Services/BulkPackageUpdater.cs:126-130, 160-171 — the finally blocks call SaveAsync(..., cancellationToken) with the same token that caused the abort. On Ctrl+C the save throws OperationCanceledException immediately, so the package cache is not persisted; and because SavePackageCacheAsync runs first in UpdateRepositoriesAndTrackingAsync's finally, its throw also skips SaveTrackingCacheAsync.

Failure scenario

User cancels mid-repo: package-version lookups fetched during the current repo (exactly what the cache exists to avoid re-fetching) are lost and re-queried from NuGet on the next run. Loss is bounded per repo due to per-repo saves, but the finally blocks accomplish nothing in exactly the case they were written for.

Suggested fix

Save the caches in the finally with CancellationToken.None (the writes are small local files), or catch OperationCanceledException around each save so one failed save does not skip the other.

Scope

• src/Credfeto.DotNet.Repo.Tools.Packages/Services/BulkPackageUpdater.cs