fix(power): popup edits update active power profile; disable redundant model picker

[FuJacob]

Summary

Two fixes to power-based model switching. (1) In the menu bar popup, changing Engine/Model while switching is on now writes the current power source's profile (battery vs. plugged-in) instead of calling selectEngine/selectModel directly, which the power switcher reverted on its next evaluation, making the popup appear to reset the user's choice. (2) The Settings > Models "Selected Model" picker is disabled while switching is on, since the Power section's per-source pickers are the source of truth.

Validation

xcodebuild -project Cotabby.xcodeproj -scheme Cotabby -destination 'platform=macOS' build
# ** BUILD SUCCEEDED **

Linked issues

(none)

Risk / rollout notes

• Plumbs PowerSourceMonitor through AppDelegate -> CotabbyApp -> MenuBarView so the popup knows the current power source.
• Behavior only changes when power-based switching is enabled; default-off path is unchanged.
• Also carries in-progress WritingPaneView edits and adds FAQ.md.

Greptile Summary

Fixes two related bugs in power-source-driven model switching: menu-bar engine/model edits now write through the active power-source profile instead of bypassing it, and the Settings › Models "Selected Model" picker is disabled while power switching is on. The PR also ships a FAQ document and simplifies the custom word-count stepper labels in WritingPaneView.

• MenuBarView: selectedEngineBinding and selectedModelBinding now route edits through applyProfileForCurrentPowerSource, which writes the battery or plugged-in profile so the power-switcher observer picks up the change rather than reverting it.
• EngineAndModelPaneView: The Selected Model picker gains a .disabled(isPowerBasedModelSwitchingEnabled) guard and context-sensitive description, consistent with how the Power section's per-source pickers own the active model.

Confidence Score: 3/5

The menu-bar fix is correct and well-reasoned, but a parallel gap in the Settings pane means the Engine picker there can still be silently overridden.

The selectedEngineBinding in EngineAndModelPaneView still calls selectEngine directly, so a user who changes the engine from the Settings pane while power-based switching is on will see their choice quietly reverted the next time any profile trigger fires — the exact class of bug the PR fixes in the menu bar, left unaddressed in the Settings view.

Cotabby/UI/Settings/Panes/EngineAndModelPaneView.swift — the Engine picker's binding needs the same treatment (disabled with explanation, or routed through the profile) as the Model picker directly below it.

Important Files Changed

Filename	Overview
Cotabby/App/Core/AppDelegate.swift	Exposes powerSourceMonitor as a stored property on AppDelegate, mirroring the pattern used for other services; straightforward plumbing change.
Cotabby/App/Core/CotabbyApp.swift	Threads powerSourceMonitor from AppDelegate into MenuBarView; a one-line addition to an existing argument list, no issues.
Cotabby/UI/MenuBarView.swift	Engine and model bindings now write through the active power-source profile instead of calling selectEngine/selectModel directly; the new applyProfileForCurrentPowerSource helper is correct.
Cotabby/UI/Settings/Panes/EngineAndModelPaneView.swift	The Selected Model picker is correctly disabled with updated helper text. However, the Engine picker at the top of the pane still calls selectEngine directly and is not disabled, which leads to silent reverts when power-based switching is on.
Cotabby/UI/Settings/Panes/WritingPaneView.swift	Replaces inline TextField labels on custom word count steppers with display-only Text; removes direct numeric input, making large value changes tedious.
FAQ.md	New FAQ document covering install, privacy, permissions, and usage; content aligns with observed app behavior.

Sequence Diagram

sequenceDiagram
    participant User
    participant MenuBarView
    participant PowerSourceMonitor
    participant SuggestionSettingsModel
    participant CotabbyAppEnvironment

    Note over MenuBarView: isPowerBasedModelSwitchingEnabled = true

    User->>MenuBarView: Change Engine or Model picker
    MenuBarView->>PowerSourceMonitor: isPluggedIn?
    alt Plugged in
        MenuBarView->>SuggestionSettingsModel: setPluggedInProfile(profile)
    else On battery
        MenuBarView->>SuggestionSettingsModel: setBatteryProfile(profile)
    end
    SuggestionSettingsModel-->>CotabbyAppEnvironment: "@Published batteryEngine/pluggedInEngine fires"
    CotabbyAppEnvironment->>SuggestionSettingsModel: selectEngine(profile.engine)
    CotabbyAppEnvironment->>RuntimeBootstrapModel: selectModel(profile.filename)

    Note over MenuBarView: isPowerBasedModelSwitchingEnabled = false

    User->>MenuBarView: Change Engine or Model picker
    MenuBarView->>SuggestionSettingsModel: selectEngine(engine) / selectModel(filename) directly

Loading

Comments Outside Diff (1)

1. Cotabby/UI/Settings/Panes/EngineAndModelPaneView.swift, line 344-349 (link)

   Engine picker not disabled/guarded when power-based switching is on

   selectedEngineBinding in EngineAndModelPaneView still calls suggestionSettings.selectEngine directly. This is the same pattern the PR fixes in the menu bar: when power-based switching is enabled, selectedEngine will be silently overwritten by applyPowerProfile the next time any profile trigger fires (power source change, model-list refresh, etc.). Meanwhile the Model picker right below it is correctly disabled with an explanation — leaving the Engine picker editable creates a confusing inconsistency where the change appears to stick in the UI but is quietly reverted later.

   

_{Reviews (1): Last reviewed commit: "fix(power): popup edits update active po..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[greptile-apps]

Direct numeric input removed from custom word count steppers

Replacing the labeled TextField with a display-only Text means users can no longer type a value directly; they must click the stepper arrow once per word, which is impractical when jumping from, say, 5 to 50. The old TextField(…, format: .number) approach provided instant entry at no extra complexity cost. Worth confirming this simplification is intentional before shipping.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!