fix(settings): keep Sparkle from starting in a UI test launch - #2823

Every UI shard on main has been red since #2813. Its own PR run failed the same way, and so did main runs 34741579313, 34748586282 and 34761684412. The last green run was 3bf3025.

Root cause

Sparkle's permission prompt took the key window. Before #2813, UpdaterBridge.init set automaticallyChecksForUpdates on every launch. That persisted SUEnableAutomaticChecks, which as a side effect stopped Sparkle from ever asking. #2813 removed the write, as SPUUpdater.h says to. Info.plist does not declare the key either, so on a runner whose defaults are empty, Sparkle asks "Check for updates automatically?" from the app's second launch on (SPUUpdater.m, startUpdateCycle).

• The UI test sandbox redirects the app's own defaults, Application Support and keychain. Sparkle reads the main bundle's NSUserDefaults.standardUserDefaults, which the sandbox cannot reach.
• The prompt opens as the main, keyboard-focused window and the app's own window is listed after it. app.windows.firstMatch then resolves to the prompt, and typed keys go to it.
• This is in the element tree of 13 failing tests in 11 suites in run 34761684412: CellImageViewer (2), ColumnJump, BackupScopeSheet, ColumnDefaultPicker (2), ConnectionActivityFooter, EditorAutocompleteFocus, EditorClipboard, ExportOptions, FindBarTabSwitch, ConnectionClose and ForeignKeyPicker.
  • ForeignKeyPicker passed on retry. Its Return key answered "Check Automatically", which turned automatic checks and installs on in that runner's real domain for the rest of the shard.
• It passes locally because a Mac that has run TablePro before already has SUEnableAutomaticChecks set.

SoftwareUpdateSettingsUITests, added in #2813, has never passed on CI, for two reasons of its own:

• testSoftwareUpdateControlsAreOffered queried checkBoxes, but the grouped Form renders both toggles as switches.
• testCheckFrequencyOffersDailyAndWeekly only passed where automatic checks were already on. On the runner the toggle read off, so the picker was disabled and the click opened nothing.

Fix

• UpdaterBridge does not start Sparkle when storage is isolated (AppStorageEnvironment.isIsolated, true only under TABLEPRO_UI_TEST_SANDBOX). A UI test or docs screenshot launch gets no permission prompt, no scheduled or background check, no download or install, and no write to the real domain. The settings pane still reads Sparkle's values, since those getters do not need a started updater. A shipped build still passes startingUpdater: true.
• SoftwareUpdateSettingsUITests:
  • queries switches;
  • pins -SUEnableAutomaticChecks YES in the argument domain for the frequency test, which is read first and never persisted, and asserts the picker is enabled before clicking it;
  • adds testATestLaunchNeverStartsTheUpdater. It asserts Settings' Check for Updates button is disabled, with automatic checks pinned off, so a started updater neither prompts nor begins a check that would also disable the button.

No CHANGELOG entry: nothing user-visible changes.

Verification

• The UI shards of this PR's own run are the discriminating check. A local Mac cannot reproduce the prompt without deleting its real Sparkle preferences.
• CI run 34769498174:
  • all three UI shards pass: 52, 52 and 51 cases, 0 failures and no retries, including every suite listed above;
  • all three SoftwareUpdateSettingsUITests cases pass;
  • unit tests pass.
• Not run locally. The local UI run could not start: macOS held an unanswered "Enable UI Automation" prompt, and every runner timed out enabling automation mode.
• Evidence: the element-tree attachments from run 34761684412, exported per shard. 13 failing trees contain the prompt window. The SoftwareUpdateSettingsUITests trees show Switch elements, and a Disabled frequency picker beside a toggle reading 0.
• Sparkle 2.9.5 source:
  • SPUUpdater.m startUpdateCycle: the prompt condition;
  • SUHost.m: standard defaults for the main bundle, and a string YES accepted from the argument domain;
  • SPUUpdater.m: settings getters and setters work on an updater that was never started, and checkForUpdates there only logs.
• Local:
  • Debug build compiles;
  • swiftlint lint --strict on both files: 0 violations.
• Review: three read-only reviewers tried to refute the root cause, the side effects of not starting the updater, and the tests' determinism. Nothing survived above low severity. Two low findings are folded in:
  • ForeignKeyPicker counted as a prompt failure;
  • automatic checks pinned off in the new test.

Not changed here

• The unit-test host process still starts Sparkle, because it runs without the sandbox variable. No assertion depends on it and unit tests pass, but it writes SUHasLaunchedBefore to the real domain. That predates this PR.

https://claude.ai/code/session_01373GBhF8GLfq9E4SHffNh4