remove shared screenResult objects

[timlenardo]

Instead of having a shared "ScreenResult" object on the AccessibilityNotificationsManager, we should create them when loading context, and pass them to the OnitPanelState to generate the context objects.

I've noticed a number of bugs in the Context adding: for example, sometimes, the context loads and it has the text from some other application. I suspect that moving away from the shared 'ScreenResult' object will solve some of these issues.

A few notes

1. The QuickEditManager was still using the ScreenResult object. To make it work, I've added a published 'selectedText' field to the AccessibilityNotificationsManager. This isn't the correct pattern: I will replace it in a follow-up refactoring task to pull all the 'highlightedText' logic into a new HighlightedTextManager. The AccessibilityNotificationsManager should not be in charge of managing that state.
2. This will break the AccessibilityNotificationsManager's debugView, but we are not using it anymore anyway. I will file a follow-up ticket to remove that codepath entirely.

[greptile-apps]

Greptile Summary

This PR refactors the context loading architecture by eliminating a shared ScreenResult object from AccessibilityNotificationsManager that was causing context contamination bugs. Previously, the system used a single global ScreenResult instance that could be overwritten by concurrent operations, leading to situations where context from one application would appear in another application's context.

The refactoring introduces several key changes:

1. New ScreenResult struct: A standalone ScreenResult struct is created in Data/Structures/ScreenResult.swift with comprehensive initialization options and proper encapsulation of application context data.

2. Context creation moved to ContextFetchingService: Instead of mutating a shared object, ContextFetchingService now creates individual ScreenResult instances for each context operation and passes them to OnitPanelState.addAutoContext().

3. Parameter-based data flow: The addAutoContext method signature is updated to accept an optional screenResult parameter, making each context operation self-contained and eliminating race conditions.

4. Temporary selectedText property: A @Published selectedText property is added to AccessibilityNotificationsManager to maintain compatibility with QuickEditManager, though this is acknowledged as a temporary solution until highlighted text logic is moved to a dedicated manager.

This architectural shift moves from a shared mutable state pattern to a more functional approach where data flows explicitly through method parameters, improving isolation between context operations and preventing cross-contamination.

Confidence score: 3/5

• This PR has a significant architectural improvement but introduces some inconsistencies that could cause issues
• The main concern is the inconsistent data source usage in QuickEditManager's caretDidDisappear() method, which uses a different source than the text selection monitoring setup, potentially creating race conditions
• Files that need more attention: macos/Onit/UI/QuickEdit/QuickEditManager.swift for the data source inconsistency issue

_{5 files reviewed, 3 comments}

_{Edit Code Review Bot Settings | Greptile}

[Niduank]

We should create a ticket to:

• Remove the showDebug functions from AccessibilityNotificationsManager and ContextFetchingService
• Ensure consistency of the highlightedText source in QuickEditManager and test it in Tethered mode

Other than that, not much.

[lk340]

Just a couple of nits!

[lk340]

We can use our accessibilityManager property here

[timlenardo]

@lk340 - I am going to handle your nits in a separate PR since it will be painful to keep this in tandem with the new repository. Merging!