[General] Better per-application onboarding and mitigation for accidental invocation

### Description of the new feature / enhancement

Several PowerToys utilities may be triggered accidentally via their shortcuts, and when activated, they do not announce themselves or provide any clear on-screen indication that a PowerToys application is responsible for the change in system behaviour. This is particularly problematic for new users who are unfamiliar with the full suite of utilities bundled with PowerToys.

The following utilities are examples of tools that can be invoked unexpectedly, listed by their default state and whether they present any identifying UI:

| Utility | Enabled by Default | Identifying UI |
|---|---|---|
| CursorWrap | ❌ No | ❌ No UI |
| Find My Mouse | ✅ Yes | ❌ No UI |
| Mouse Highlighter | ✅ Yes | ❌ No UI |
| Mouse Jump | ❌ No | ✅ Has UI |
| Mouse Pointer Crosshairs | ❌ No | ✅ Has UI |
| Peek | ✅ Yes | ✅ Has UI |
| Advanced Paste | ✅ Yes | ✅ Has UI |
| Color Picker | ✅ Yes | ✅ Has UI |
| Shortcut Guide | ✅ Yes | ✅ Has UI |
| PowerToys Run | ✅ Yes | ✅ Has UI |
| ...possibly others | | |

Even tools that *do* have UI often do not clearly brand themselves as PowerToys utilities, potentially leaving users confused about what activated and how to configure or dismiss it.

### Proposed mitigation
Upon activating any PowerToys utility, show an unobtrusive toast notification that identifies the tool and clearly shows that it is a PowerToys application, e.g.:

> **PowerToys Mouse Highlighter activated**
>
> Click here to customize or disable Mouse Highlighter.

Clicking the toast would open the Settings page for that specific utility.

**Dismissing the toast**
This is up for discussion. We could:

- Only show the toast once per application, on first activation, and accept the risk that the user could miss it or accidentally dismiss it immediately; or
- Show it for a limited number of activations; or
- Show it for a limited number of days; or
- Show it if the user has not used the application for X number of days; or
- Show it with a "Do not show again [ ]" UI element, with the checkbox permanently disabling the notification for that application.

Experienced users could control the visibility of all notifications through a single new setting, e.g. "Show first-run notifications for applications."

### Scenario when this would be used?

This feature addresses a well-documented class of user confusion where PowerToys utilities are accidentally triggered and the user has no idea what happened or how to undo it. This is a consequence of most PowerToys applications being enabled by default.

### Scenario 1: Accidental activation with no identification

Most recently, a user reported Find My Mouse being activated accidentally and detailed their frustration at not knowing what the culprit was. See #45920.

The default keyboard shortcut to trigger PowerToys Run is Alt+Space, which conflicts with the in-built Windows menu shortcut. Although the new Settings UI reports most Windows shortcut conflicts, this is absent, resulting in confusion. (See #17252 and #37497).

### Scenario 2: Tool gets stuck with no way to identify or dismiss it

A user accidentally opened the overlay for the Shortcut Guide and somehow it stayed open even after they released the Windows key and had no way of closing it, _nor was there any indication of what it was while it was open_. They explicitly requested: "Please add some sort of name to the top of the overlay, preferably add a taskbar entry that can be right-click closed and ideally have the same key that opens it, close it in cased[sic] this happens again." (See #6726.)

### Scenario 3: New users struggle to remember which tools exist and what their shortcuts are

One user noted "As a new user to Powertoys, I see the potential of **many** of the toys within. But being a new user, its hard for me to remember all of the useful shortcuts." (See #42940.)

A first-activation toast notification would address these scenarios by: identifying the tool that just activated, providing a direct path to the specific Settings page for the application; allowing the user to customise or disable it; and educating the user that the behaviour is caused by PowerToys and not a built-in Windows feature or another utility.

### Supporting information

- **Issue #26816** The core problem is acknowledged here, and this led to the new homepage UI with the modules list Dashboard. However, the Dashboard addresses *proactive discovery* (browsing Settings) but does not address *reactive discovery* (a tool fires unexpectedly and the user doesn't know what it is).

- **Issue #37497** This demonstrates a user accidentally triggering PowerToys Run and being unable to identify what it was.

- **Issue #6726** - Teh Shortcut Guide issue, where the guide lacks identifying information.

- **Issue #42940** and **Issue #21226** - Both request better discoverability for PowerToys shortcuts, indicating that users struggle to learn and remember what tools are available.

### Design considerations

- A small in-app flyout is recommended, with a generous timeout and/or a click-to-dismiss function, limiting the ability for a user to accidentally dismiss the toast or to miss it entirely if they're in Do-not-disturb mode.
- Clicking the toast should deep-link to the specific utility's Settings page.
- For tools with no UI at all (e.g., Find My Mouse, Mouse Highlighter, CursorWrap), the toast is especially critical, as there is otherwise no on-screen element that identifies what is happening.

Start by reviewing the referenced issues (#45920, #17252, #37497, #6726, #42940, and #21226) and the listed utility activation scenarios; no source files, tests, or entry points are identified. A complete solution would define per-utility first-activation notifications, deep-linking to each utility's Settings page, and a dismissal or suppression policy.

Written by the indexing model from the issue text.