Test window state changes through the buttons present on the window's chrome

### What is the problem or limitation you are having?

Related PR: #2364

### Context:
There are 2 ways that a window's state can be changed.
1. Through the native window state APIs.
2. Through the buttons present on the window's chrome.

From preliminary testing, it seems that changing the window state through the native APIs has a slightly different behavior than changing the window state through the buttons on the window's chrome(At least on winforms from current testing).

Currently, the testbed is only testing window state changes which are triggered through the APIs. But it is not testing window state changes which could be triggered by the user directly using the buttons on the window's chrome, or restoring them from the taskbar/dock.

This gap in testing can become problematic, as users are more likely to change window states using the buttons on the window's chrome. Such a gap could conceal potential behavioral bugs that differ from the behavior observed when using the APIs.

### Additional context
To implement such tests, new probe methods need to be developed. I will add more context on how these probe methods could be added later on.

Start by locating the testbed's existing window-state tests and compare coverage for native window state APIs with user actions on the window chrome. Investigate how probe methods could exercise the chrome buttons and restoring from the taskbar or dock. Done means the testbed covers these user-triggered state changes and captures platform-specific behavior.

Written by the indexing model from the issue text.