[Pipeline Bug]: installationmetadata exe add does not apply the argument to the triggered validation run (no .validation persisted)

Nobody has claimed this yet.

## Summary

`@wingetbot installationmetadata exe add ` records the argument mapping and triggers a new validation run, **but the triggered run does not invoke the executable with the mapped argument.** The exe is launched bare, so a portable CLI that requires a subcommand/argument re-fails `Validation-Executable-Error` (non-zero exit), and because the argument-run never *succeeds with the argument*, the backend **never persists the `.validation` file** for the package. The net effect: the command cannot clear the error on its own, a moderator must manually install-test and hand-toggle labels to merge, and no metadata is persisted — so the **next version of the same package hits the identical wall**.

## Repro / evidence (live case: PR #390556 — facebook.pyrefly 1.1.1)

`facebook.pyrefly` is a portable Rust CLI (`zip` -> `NestedInstallerType: portable`, x64 + arm64). Bare invocation prints usage and exits `2` (clap "missing required ``"), which is expected for this CLI — hence the need for an arg mapping.

1. **17:00:53** — `@wingetbot installationmetadata exe add pyrefly.exe --version` (posted by a WinGet Collaborator).
2. **17:01:12** — build [360260](https://dev.azure.com/shine-oss/8b78618a-7973-49d8-9174-4360829d979b/_build/results?buildId=360260) triggered; `Validation-InstallationMetadata-Update` label applied.
3. **Build 360260 ran the exe BARE.** `InstallationVerificationLogs` install-client log:
```
Launching executable file: C:\Users\Validator\AppData\Local\Microsoft\WinGet\Packages\facebook.pyrefly__DefaultSource\pyrefly.exe
Executable ...\pyrefly.exe returned exit code: 2
```
No `--version` on the command line. `ValidationResult/InstallationVerification_Result.json` -> `ExeRunInfo` for both x64 and arm64 shows `ExitCode: 2`, `ExecutionStatusResult: Fail`, and `ErrorStream` = pyrefly's bare usage banner. Had `--version` been applied, pyrefly would have printed its version and exited `0` (its own usage lists `-V, --version Print version`).
4. **18:29:38** — `wingetbot` re-applied `Validation-Executable-Error` (still failing).
5. **19:36:59–19:37:02** — a moderator (`stephengillie`) assigned himself, manually install-tested, and **hand-toggled labels** (removed `Validation-Executable-Error` + `Validation-InstallationMetadata-Update`, added `Validation-Completed`) to move the PR forward. No automated arg-run succeeded; **no `.validation` file was written** to the package (confirmed — none present on the PR).

## Expected behavior

The validation run triggered by `installationmetadata exe add ` should invoke `` **with ``**. On a successful (exit-0) run, the backend should persist the `.validation` file (Executables arg mapping) at the package root so the error clears automatically and future versions inherit the mapping.

## Actual behavior

The triggered run invokes the exe bare; the argument is not applied. `Validation-Executable-Error` cannot be cleared by the command; no `.validation` file is persisted; a human must manually validate and adjust labels every time.

## Impact

Every portable-CLI package whose smoke-test needs an argument (very common: clap / System.CommandLine tools that require a subcommand) is affected. Each requires manual moderator intervention and leaves no persisted metadata, so the problem recurs on every subsequent version.

## Notes

Filed from triage. Diagnosis assisted by GitHub Copilot.

Start with the `@wingetbot installationmetadata exe add ` entry point and inspect the triggered validation using `ValidationResult/InstallationVerification_Result.json`. Confirm whether the executable receives the mapped argument and whether a successful run writes the `.validation` file at the package root; done means the error clears automatically and future versions inherit the mapping.

Written by the indexing model from the issue text.