[LMC-Karma]

Problem

Every swift test run left one or two empty BetterTileIconTests-*.plist
files in ~/Library/Preferences. The icon test used a named UserDefaults
suite and deleted its file at the end, as #138 added. The preferences daemon
wrote the file again a few seconds after the test ended, so the delete could
not win. 691 such files had built up since the icon picker landed in #109.

Change

The icon test uses in-memory defaults, so it never reaches the disk. It still
checks that the saved choice is read back and that an unknown value falls back
to Classic.

Evidence

• Before: one run of appIconChoiceRestoresAndFallsBackToClassic on main
  left 0 new files right after the run and 2 new files 8 seconds later. Each
  was 42 bytes and contained {}.
• After: the same run left 0 new files after 8 seconds. A full swift test
  run also left none.
• Checks run and results: swift test passes (all three test targets). The
  Debug xcodebuild with CODE_SIGNING_ALLOWED=NO succeeds.

Limits

• Checks not run and why: no live check, because only a test file changed.
• Remaining uncertainty: the test no longer checks that a second
  UserDefaults instance sees a saved value. That is UserDefaults behavior,
  not BetterTile's.

The 691 leftover files on the maintainer's Mac were deleted by hand.

Safety

None. Test code only.

🤖 Generated with Claude Code

[claude]

Review summary

Scope matches the stated goal: this only touches the test file, replaces the disk-backed UserDefaults(suiteName:) fixture with an in-memory UserDefaults subclass, and keeps the fallback-to-Classic check. No BetterTileCore/AppKit/coordinate, WindowCoordinator, networking, permissions, private-API, or updater rules are touched, so SECURITY.md and the architecture limits in AGENTS.md don't apply here.

One confirmed problem, left as an inline comment: the new single-instance MemoryDefaults can no longer verify that a saved icon choice is visible to a second reader, which is the actual "restore at launch" behavior appIconChoiceRestoresAndFallsBackToClassic is meant to cover (AppIconStyle.apply() reads from a fresh UserDefaults.standard at launch). The old test built a second UserDefaults(suiteName:) instance for exactly this reason; the PR body's Limits section notes the gap but attributes it to "UserDefaults behavior, not BetterTile's," which undersells it. Suggest backing MemoryDefaults with a shared store so a second instance can be constructed over the same backing dict.

Not verified: this review ran without macOS/Xcode available, so I could not reproduce the before/after ~/Library/Preferences evidence or run swift test myself. I'm treating the stated empirical results as given rather than as a fault of the PR.