fix(audio): route follows-default apps when highest-priority output reconnects

[clem-git]

Problem

Addresses #255. On a Bluetooth output reconnect, the system default and the UI correctly move to the reconnected device, but per-app audio (follows-default apps, e.g. Spotify) keeps playing on the previous device (typically the built-in speakers). The user has to manually toggle the output in FineTune to make audio actually follow.

Reproduced on macOS 26.4.1 with FineTune 1.7.0:

• Priority list had a disconnected device as the top priority and the connected headset ranked just below it.
• macOS reported the headset as the default output, FineTune's UI showed it as active, Spotify's level meter was live — yet audio came from the laptop speakers.

Root cause

In handleDeviceConnected, macOS natively auto-switches the system default to a newly connected BT device within milliseconds. By the time the handler runs, deviceUID == currentDefault, so the existing branching matched neither case:

if isNewDeviceHigherPriority, deviceUID != currentDefault {   // false: already default
    reEvaluateOutputDefault()
} else if !isNewDeviceHigherPriority, currentDefault == deviceUID {  // false: it IS higher priority
    restoreConfirmedDefault()
}

Result: lastConfirmedDefaultUID stays stale on the old device and routeFollowsDefaultApps is never called, so the app taps are never re-pointed. A subsequent handleDefaultDeviceChanged (Case 1) then treats macOS's switch as something to undo and routes follows-default apps back to the stale device — stranding audio on the old output while the system default sits on the new one.

Fix

Extract the decision into a pure, testable connectedOutputDefaultAction(...) and add the missing .confirmConnected case: when the connected device is the highest-priority connected device and macOS already made it the default, confirm it (lastConfirmedDefaultUID) and route follows-default apps so their taps follow.

The existing .switchToConnected (higher-priority reconnect, not yet default) and .restorePrevious (lower-priority device macOS hijacked to) behaviours are preserved exactly — lower-priority-hijack protection is unchanged.

Testing

• New OutputDeviceReconnectRoutingTests covers the reconnect desync (the previously-unhandled case) and the preserved protection behaviour, including the "disconnected top-priority device → highest connected device still wins" scenario.
• Full FineTuneTests target passes.
• Manually verified on a local ad-hoc build: with the patch, audio follows to the reconnected headset automatically; without it, it stranded on the speakers until a manual toggle.

🤖 Generated with Claude Code