RichTextBox always sends its entire contents as an accessibility event on focus

### .NET version

10.0.202

### Did it work in .NET Framework?

Not tested/verified

### Did it work in any of the earlier releases of .NET Core or .NET 5+?

_No response_

### Issue description

I previously opened an issue about this, but it got closed and the discussion locked after just a little bit of inactivity. However, I'm once again running into this, so re-creating an issue, as I believe the original reasoning for closing it is flawed.

If I create a RichTextBox, alt+tab away from the window, and alt+tab back, both JAWS and NVDA report the entire contents of the RichTextBox as its own accessibility event. This is not standard behavior. Oddly enough, narrator is not effected, reading nothing at all when the control takes focus.

```csharp
using System.Windows.Forms;

ApplicationConfiguration.Initialize();
Form mainForm = new() { Text = "RichEdit Test", Width = 450, Height = 250 };
RichTextBox textBox = new() {
AccessibleName = "Content",
Text = "This is a test\r\nthat spans multiple\r\nlines.",
Size = new Size(400, 200),
Location = new Point(10, 10)
};
mainForm.Controls.Add(textBox);
Application.Run(mainForm);
```

### Reason for re-creating

In #12772, @merriemcgaw said:

> There is some risk in the implementation options available to us. After talking with our internal accessibility team, it seems that there is an easy way for the screen reader user to "hush" the reading once focus is received. In that case we don't have a compliance issue, and with the risk of making changes here it's better to let the additional content be sent to the AT.

I completely disagree with this assertion; this is 100% a compliance issue in my mind as a screen reader user who is also a software engineer.

The assertion that a user can simply "hush" the screen reader completely misses the reality of real-world application performance and UX. In my development work, I'm building a large-scale e-book and document reader. I ended up going with wxWidgets as a native widgets abstraction due to this Winforms bug, because when a RichTextBox holds an entire book, loading several megabytes of text into the control means that megabytes of data are forced across the MSAA/UIA boundary instantly upon focus, every, single, time. This can even freeze screen readers.

The argument that this isn't a compliance issue also falls flat when you look at how other standard Win32 and Windows Forms controls behave: A standard multi-line TextBox does not dump its entire contents into a focus event on Alt+Tab; it respects the cursor position or selected text. Microsoft Word and Notepad do not dump entire documents into the accessibility channel on focus either. Furthermore, as noted in the reproduction steps, Windows Narrator reads nothing at all on focus, proving that the underlying event emission is inconsistent and broken depending on how the AT consumes the UIA/MSAA tree for RichEdit.

If standard text input fields can handle focus gracefully without flooding the AT channel, RichTextBox should be held to the same standard. Leaving this unfixed effectively breaks the usability of RichTextBox for any accessibility-compliant application handling large text payloads, such as my Paperback ebook reader.

### Steps to reproduce

1. Run the provided code with NVDA or JAWS active.
2. Alt+tab away from the window and back.
3. Note that the entire content gets read, not just the currently focused line.

Start with the provided C# reproduction and run it with NVDA or JAWS, then compare the RichTextBox focus event with the standard multiline TextBox behavior described in the issue. Done means returning to the window does not emit the entire control contents as an accessibility event, while the reported focus behavior remains usable.

Written by the indexing model from the issue text.