Add Dragonfly accessibility path for text manipulation

[taherdhanera]

Description

Adds an optional Dragonfly accessibility path for Caster text manipulation commands.

The change keeps the existing clipboard-based implementation as the fallback, but first tries the focused Dragonfly accessibility text model when it is available. That gives move, grab, replace, remove, and ... until ... commands a way to operate through OS accessibility-backed text ranges instead of always selecting/copying through the clipboard.

This does not add a new OS accessibility backend or a new dependency. It uses Dragonfly's existing accessibility controller surface and the focused text object that Dragonfly already exposes.

Related Issue

Refs #814

Motivation and Context

Issue #814 asks for integration with OS accessibility APIs for Select-and-Say-style text navigation. In the issue discussion, the preferred direction was to use Dragonfly's existing accessibility controller rather than introducing a separate Caster-specific accessibility plugin. This PR is a first Caster-side integration slice: if Dragonfly can see focused editable text, Caster uses it; if not, behavior falls back to the current clipboard path.

How Has This Been Tested

• Added unit tests for the accessibility search-window/range logic and fake focused accessibility text selection/cursor movement.
• Ran git diff --check successfully.
• I could not run the Python unittest suite locally because this shell does not have a Python executable on PATH. The added tests are intended to run in CI with the repo's normal Python test environment.

AI assistance note: this implementation was AI-assisted and manually scoped/reviewed against the existing Caster text manipulation code and Dragonfly accessibility docs. No generated third-party plugin code was copied into the repo.

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue or bug)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Renamed existing command phrases (we discourage this without a strong rationale).

Checklist

• I have read the CONTRIBUTING document.
• My code follows the code style of this project.
• I have checked that my code does not duplicate functionality elsewhere in Caster.
• I have checked for and utilized existing command phrases from within Caster (delete if not applicable).
• My code implements all the features I wish to merge in this pull request.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests pass.

Maintainer/Reviewer Checklist

• Basic functionality has been tested and works as claimed.
• New documentation is clear and complete.
• Code is clear and readable.