fix: deadlock between Task.Size and redrawProgress under parallel install

[mcharles-square]

Summary

#558 parallelised hermit install, which lets many goroutines drive per-package download progress concurrently. cache/http.go calls task.Size(total) followed by task.Add(n) for each chunk received; with a single active task the cycle below could never close, but with many it closes in two hops.

Lock orderings:

Task.Size:           task.lock -> ui.lock        (via UI.swapSize)
UI.redrawProgress:   ui.lock   -> task_i.lock    (via liveOperations / op.status)

Goroutine A inside task_A.Size holds task_A.lock waiting on ui.lock. Goroutine B, having just returned from its own task.Add's critical section, enters redrawProgress holding ui.lock and iterates operations waiting on task_A.lock. Deadlock is silent because the UI itself is blocked, so no progress output is produced before the job is killed — matches the wild symptom of hermit install stalling with zero output after v0.52.0 on CI jobs that install many packages at once.

Fix

Release task.lock in Task.Size before calling UI.swapSize. The oldSize → newSize delta passed to swapSize is additive and commutative, so doing the swap outside the task's critical section loses nothing.

Test

ui/task_test.go::TestConcurrentTaskSizeAndAddNoDeadlock fans out goroutines each interleaving Size/Add on their own task (mirroring cache/http.go's download loop).

• Pre-fix: hangs for the test's 10s self-deadline and fails with an annotated goroutine dump showing the expected ui.lock ↔ task.lock cycle.
• Post-fix: completes in ~0s.

Passes go test -race ./ui/ and existing go test ./app/.