fix: Release only ToolTips the service opened - #26096

Looks good. This is a faithful port of WinUI's automatic-ToolTip tracking:

• m_bIsOpenAsAutomaticToolTip is captured from s_bOpeningAutomaticToolTip when the ToolTip opens (ToolTip::OnIsOpenChanged, ToolTip_Partial.cpp:277).
• The service lets go of the ToolTip only when that flag is set (:392).
• The service sets the static around its own put_IsOpen(TRUE) (OpenAutomaticToolTip).

CloseToolTipImpl and the show-duration timer still clear m_CurrentToolTip before closing, so the #25137 leak stays fixed. Nothing below blocks merging.

1. When_Pending_ToolTip_Opened_And_Closed_By_App_Then_Still_Opens_Automatically can flake.
The mouse move, the app's open/close and three WaitForIdles all have to finish inside the show delay. That is 1000 ms on Uno, and 800 ms (600 ms on reshow) on native WinUI, where this test also runs.

If the open timer fires while the app holds the ToolTip open, IsOpen = true doesn't change anything, so the open is never flagged. The app's close then releases nothing, nothing reopens the ToolTip, and the test fails with "did not open".

Changing FeatureConfiguration.ToolTip.ShowDelay in the test won't help, because EnsureOpenTimer reads the interval only once, when the static timer is created.

The behaviour under test runs synchronously in the property-changed callback, so I'd suggest:

• set toolTip.IsOpen = true; toolTip.IsOpen = false; back to back, with no waits in between;
• under HAS_UNO, assert ToolTipService.CurrentToolTipForTesting is still the ToolTip right after the close, which checks the regression without depending on the timer.

2. The second test's comment claims more than the test checks.
"A reopen is the app's to close" holds only for the show-duration timer. CloseToolTipImpl (ToolTipService.cs:141) still sets toolTip.IsOpen = false no matter who opened it, so these still close a ToolTip the app reopened:

• pointer exit
• KeyDown
• a pointer press on a ButtonBase
• LostFocus
• the owner becoming invisible

WinUI's CancelAutomaticToolTip / CloseAutomaticToolTip only close m_tpCurrentToolTip. That behaviour predates this PR, so I'd scope the comment to the timer and track parity of those close paths separately.

3. Follow-up: one pending case is still never flagged.
If the app opens the ToolTip during the show delay and leaves it open, the timer's open is a no-op and the ToolTip is never flagged. m_CurrentToolTip still points at it, so the close timer closes the app's ToolTip after ShowDuration.

In WinUI, m_tpCurrentToolTip is only set on the automatic path, so the service never takes over that ToolTip. This also predates the PR.

4. Nit: RemoveAutomaticStatusFromOpenToolTip, which Slider calls, is still a [NotImplemented] stub. Now that the flag exists, porting it is short: stop the close timer, clear the flag, release m_CurrentToolTip.

5. Nits:

• The new tests could carry [GitHubWorkItem], like the #25137 tests next to them.
• The commit subject could use a tooltip scope: fix(tooltip): ....

CI: the WinAppSDK Sync Generator Check failure is an NU1900 network error during restore (the vulnerability-data request failed), so a rerun should clear it.

Thanks, the follow-ups look good.

• Pending test (293a11e2f7): this removes the race. CurrentToolTipForTesting is checked right after the back-to-back open/close, so the test no longer depends on the show-delay timer.
• Guard in OnOpenTimerTick (d05dac1043): this is correct. If the ToolTip is already open when the timer fires, the service now lets go of it instead of taking it over. That matches WinUI's OpenAutomaticToolTip, where setting IsOpen = true on an open ToolTip changes nothing and leaves m_tpCurrentToolTip unset. Skipping the close-timer setup is safe, since every other use of m_CloseTimer is null-checked.
• Deferred items: I agree with leaving RemoveAutomaticStatusFromOpenToolTip (it needs a Slider test) and the close paths that close an app-owned ToolTip to their own change.

One correction to my earlier review: the three new tests don't run on native WinUI (they're NotExecuted in the WinUI Runtime Tests run), so my WinUI timing concern doesn't apply.

CI on build 244142:

• WinAppSDK Runtime Tests: Given_ToolTip.When_Closed_Then_DataContext_Kept fails with content.Text "" instead of "VM1". This PR can't cause that: the WinAppSDK head doesn't compile Uno.UI, and the new tests are skipped there. The test came in with #25137 and passed on master's WinUI run (build 243954), so it looks like a new flake. Please rerun the job. Given_ScrollViewer_Zoom failing in the same job is unrelated.
• Android Skia shard 1: the Given_BitmapIcon and Given_InputPane failures are unrelated to ToolTip.