Stop layout switcher animation after dwell

[eafire15]

Summary

• bound the layout-switcher dwell pulse instead of leaving a repeatForever animation attached to a hidden SwiftUI hosting view
• preserve the visible pulse for the 0.5-second dwell interaction
• stop the post-use Core Animation / NSHostingView.layout loop reported in CPU usage #83

Root cause

DockItem starts an unbounded opacity animation while dwelling over another layout. LayoutSwitcherPanel.hide() clears the dwell state and orders the panel out, but retains its NSHostingView. On macOS 26.6.1 the repeat animation can remain active after every MacsyZones window is offscreen.

A triggered sample of v3.0.4 showed the main thread repeatedly flushing Core Animation transactions and laying out the SwiftUI hosting view, with repeat-animation frames in the hot path.

Verification

Release builds were compared with an identical temporary internal probe that presents the switcher, sets a dwell target, clears it, and hides the panel. The probe was removed from this branch after calibration.

Five paired runs, after a 10-second cooldown and discarding the first top interval:

Variant	Mean post-hide CPU
repeatForever	16.390%
repeatCount(2)	0.750%

Reduction: 95.42%.

The real v3.0.4 drag/dwell/release sequence measured 35.72% mean CPU over 20 post-hide samples, commonly 35–45%. A normal snap without switcher dwell returned to idle, isolating this animation path.

• Release build succeeds with CODE_SIGNING_ALLOWED=NO
• Known-bad probe retains elevated post-hide CPU
• Fixed probe drains to near-zero post-hide CPU
• No benchmark/probe code remains in production source

Scope

This intentionally does not include the separate duplicate layout-load memory fix, donation reminder behavior, updater hardening, or a broader window-lifecycle refactor.