Add a Show in Dock setting for menu bar-only use

[amrshawqy]

Summary

Adds a Show in Dock preference for people who use Speaky primarily from the menu bar.

• The preference is disabled by default.
• When disabled, Speaky stays out of the Dock while running in the background, recording, or transcribing.
• Opening or minimizing the main/settings window keeps Speaky visible in the Dock so the window remains easy to recover.
• Enabling the preference keeps Speaky in the Dock at all times.

Motivation

Speaky already provides a persistent menu-bar interface, so displaying a Dock icon while no application window is open is unnecessary for menu-bar-first workflows. This setting lets users choose between a lightweight menu-bar-only experience and the existing always-visible Dock behavior.

Behavior

Show in Dock	Main/settings window	Activation policy
Off	Closed	Accessory — hidden from Dock
Off	Open or minimized	Regular — visible in Dock
On	Any state	Regular — visible in Dock

Implementation

• Persists the new preference through AppSettings and UserDefaults.
• Adds a native toggle and explanatory text under a new Application settings section.
• Centralizes activation-policy selection in a small, testable DockVisibilityPolicy.
• Updates the policy in response to relevant main-window lifecycle events.
• Treats only titled, main-capable windows as user-facing. This excludes the menu-bar popover and DynamicNotchKit recording panel.
• Reopen handling checks specifically for a visible user-facing window, so auxiliary overlays cannot prevent the main window from reopening.

Validation

• Added tests for all Dock policy states.
• Added tests for the default preference and a complete persistence round trip.
• All 5 focused tests pass.
• git diff --check passes.
• Manually verified that the app uses regular activation while its main window is open and accessory activation after the window closes with the preference disabled.

The existing complete test suite also exposed two unrelated, order-dependent TranscriptionCoordinatorTests failures caused by shared UserDefaults state during parallel execution; both tests pass when run independently.

Scope

This PR intentionally contains no generated Xcode project, app binary, dependency change, version bump, or unrelated audio/build-identity work.