Explore remaining stale single-ruler assumptions

[pascalpp]

Follow-up from the issue #272 pass. I did not see another obvious “only the first/one ruler works” bug, but a few areas still encode older single-ruler-ish assumptions and deserve focused exploration.

Candidate areas

1. RulerManager.activeController falls back to controllers.last

   • File: Free Ruler/RulerWindow.swift
   • Current behavior: when there is no valid activeRulerID and no key ruler window, activeController returns controllers.last.
   • Risk: if hidden/stale controllers remain tracked, menu actions or commands may target a hidden ruler.
   • Explore whether fallback should prefer the last visible controller, or nil when no visible/key ruler exists.

2. Singleton per-ruler Settings panel follows active-ruler changes

   • File: Free Ruler/AppDelegate.swift
   • Current behavior: one rulerSettingsController is reused and reattached when active ruler changes.
   • Risk: this may be intentional, but it is still a single “current settings panel” model layered over multiple rulers.
   • Add regression tests for: Settings open while cycling rulers, Settings open while closing active ruler, and Settings open while clicking another ruler.

3. closeKeyWindow maps only exact ruler windows to controllers

   • Files: Free Ruler/AppDelegate.swift, Free Ruler/RulerWindow.swift
   • Current behavior: controller(containing:) checks window === controller.rulerWindow.
   • Risk: child windows attached to rulers, such as the Settings panel or color panel, may make close behavior depend on fallback paths rather than explicit ownership.
   • Explore whether child-window ownership should be resolved deliberately or left to panel closing behavior.

4. Global color panel state

   • File: Free Ruler/PreferencesController.swift
   • Current behavior: color picking is coordinated through activeRulerColorWell and NSColorPanel.shared.
   • Risk: AppKit’s shared panel is expected, but interactions between app Preferences and per-ruler Settings can still feel like a single-surface assumption.
   • Explore whether switching between Preferences color well and ruler Settings color well behaves predictably when both windows are open.

Notes

The current active-ruler command model appears mostly intentional and has good coverage: commands update only the active ruler, drawing and mouse ticks iterate all visible controllers, and saved ruler state stores multiple ruler instances plus active ruler ID.

This issue is for investigation and targeted regression tests before changing behavior.