[BUG] %PACKAGE% environment variable used for update/installation copies files to erroneous location

### Please confirm these before moving forward

- [x] I have searched for my issue and have not found a work-in-progress/duplicate/resolved issue.
- [x] I have tested that this issue has not been fixed in the latest [(beta or stable) release](https://github.com/marticliment/WingetUI/releases/).
- [x] I have checked the [FAQ](https://github.com/marticliment/WingetUI#frequently-asked-questions) section for solutions.
- [x] This issue is about a bug (if it is not, please use the [correct template](https://github.com/marticliment/WingetUI/issues/new/choose)).

### UniGetUI Version

3.3.6

### Windows version, edition, and architecture

Windows 11 Pro (26200.7623)

### Describe your issue

Seemingly at random (I never changed any of the settings and the software ran as expected for several months), UniGetUI has decided to start installing updates to my installed apps in a new directory (previously, this setting was as shipped/default installation option) and new drive. However, even after choosing a custom install location for the command line parameters for one of the updates, after selecting the correct (current install location on the system drive) path for the software to install, the [BROWSE] modal closes then the %PACKAGE% environment variable is appended to whatever directory path I just chose. If I'm offered the option of selecting a directory for installation, WHY ON FUCKING EARTH WOULD ANYONE APPEND A VARIABLE OR ANY STRING TO SOMETHING I EXPLICITLY CHOSE?!?! This is horrible functionality mixed with HORRIBLE UX. For such an integral component to one's Windows system (this tool is responsible, in my situation at least, for updating nearly all of my installed software), you'd think the people responsible for releasing production code to UniGetUI software would do a decent job at QA -- but, I'm forced to uninstall this software now due to its inability to perform it's core functionality in, at least, its most fundamental way. The fact that this is even a bug tells me never to use software released by this team of "software engineers" now or in the future. The time wasted (I didn't catch the problem until after many software installs were messed up and files copied to erroneous locations) in having the uninstall and then re-install my software is inexcusable and, at this point, unforgivable.

### Steps to reproduce the issue

Fuck if I know. It just started happening in the last 24 hours. No idea why this would affect me and not a large swath, if not everyone, of users is beyond me. I haven't made any system changes nor configured this software any differently from the time when it worked properly (which I believe was only 2 days ago).

### UniGetUI Log

```text
Great job at UX again. Fuck if I can't get to it when the GitHub interface is launched in a modal from within the app. Great fucking decision making over there -- maybe you guys should give up on software development now and just let AI do it for you. I'll try to update this bug after I submit it so there's a log file though.
```

### Package Managers Logs

```text
Ditto. See above, dumbasses.
```

### Relevant information

Here's some relevant information: do a better job at QA. It's tirelessly boring and tedious. But, your software turns to shit without it. All of humans are prone to making a mistake here and there. It's the dumbasses who willfully lack the motivation to QA and see very obvious problems that elicit this sort of anger in me... as I'm sure it does in many others.

### Screenshots and videos

Try NOT launching GitHub in a modal and just use the user's system browser (like most other apps do for good reason).