Enabling "Run as Administrator" per-profile creates an inescapable loop toggle cannot be disabled through the UI

### Windows Terminal version

1.23.20211.0

### Windows build number

10.0.26100.8037

### Other Software

_No response_

### Steps to reproduce

When `"elevate": true` is written to `settings.json` under the normal user's AppData path, Terminal relaunches under the Administrator context. Once elevated, Terminal reads settings from the Administrator's AppData folder a completely separate `settings. Json` that never had `"elevate": true`. So, the UI correctly reflects the admin profile's settings, but the user's actual settings file (where the flag is set) is no longer accessible through the UI.

The user is stuck in a loop:
1. Terminal reads `"elevate": true` from the user's settings → relaunches as Admin
2. Admin session loads its own clean settings → toggle appears OFF
3. User sees no way to disable it → closes and reopens → back to step 1

**Workaround**
Manually edit `settings.json` at:
`C:\Users\\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json`

Find `"elevate": true` and change it to `false`.

**Security Concern**
Because there is no obvious way to disable this through the UI, users end up running Terminal as Administrator for an extended period without intending to. This means every command, script, and process launched from Terminal runs with full system privileges increasing the attack surface unnecessarily. Users who enabled this briefly or by accident have no clear path to return to normal user-level execution without knowing about the JSON file.

**Suggestion**
Terminal should either:
- Read the originating user's settings file when detecting that elevation was triggered by the `elevate` flag, so the toggle can be turned off from within the elevated session
- Show a warning or provide a clear "Disable elevation" option when running in an elevated state triggered by this setting
- At minimum, surface a message like "This session is elevated due to a profile setting in your user account" with a one-click fix

### Expected Behavior

_No response_

### Actual Behavior

When "elevate": true is enabled through the UI, Terminal relaunches as Administrator. Once elevated, Terminal reads settings from the Administrator's AppData folder a completely separate settings.json that never had "elevate": true. The toggle in Settings shows as OFF because it's reflecting the admin profile's settings, not the original user's settings where the flag is actually stored. There is no way to disable elevation through the UI the only fix is manually editing the JSON file at the original user's path.

The closest issues are:

#13928 / #14259 elevate: true causing crash loops, not the UI toggle trap
#12309 elevate: true in defaults overriding individual profiles, but not about the settings file mismatch between user accounts
#13197 Terminal requiring admin to launch at all, different root cause
#14624 the elevate option missing from the UI entirely

Start by reproducing the loop with the user's settings.json at the stated LocalState path, then compare it with the Administrator account's settings.json. Trace how the elevate setting and Settings UI behave after relaunching under the Administrator context. Done means an elevated session clearly exposes a way to disable the originating user's elevation setting without manual file editing.

Written by the indexing model from the issue text.