By default from ARM64 architecture projects, `WIN32` is not defined. It
is supposed to be for this proxy stub to work. So I've set it with the
preprocessor for this project.

## PR Checklist
* [x] Closes release build failure after #7489 
* [x] I work here.
* [x] Built on my machine.

## Detailed Description of the Pull Request / Additional comments

`WIN32` appears to convey two meanings depending on who you are:
- To most of Windows, `WIN32` appears to mean the Win32 API surface and
  sometimes the major OS version that goes with it. (Specifically in
  contrast to 16-bit Windows.)
- To others, `WIN32` appears to mean a 32-bit processor or a synonym of
  `x86`.

This is generally not a problem for a few reasons:
- VS defines `WIN32` in the default targets/props only for the `x86`
  processor type. **BUT**
- Windows defines `WIN32` if it's not already defined in both
  `minwinbase.h` and `ole2.h` which generally speaking manage to get
  compiled into practically everything especially since `minwinbase.h`
  tends to sneak itself in somehow through `windows.h` and that's
  **THE** include to use the Windows API surface.
- Windows also defines `WIN32` for itself unconditionally and relatively
  globally when building itself.

However, it's a problem here because: 
- `rpcproxy.h` is the only header included in `dlldata.c`, a file
  generated automatically by `midl.exe` in the SDK when making a proxy
  stub.
- `rpcproxy.h` only defines its contents for a proxy when `WIN32` or
  `_M_AMD64` are found.
- Therefore, it's defined pretty naturally for x86 and AMD64 targets
  from VS, but not for ARM64.
- ARM64 support is pretty new and those who are attempting to build for
  ARM64 and against the public SDK with Visual Studio for a classic COM
  proxy... seems like a relatively unlikely combination.

I will follow up with the Visual Studio, Windows SDK, and MIDL/COM teams
to try to remove this pitfall from the public tooling. But for now, this
is the fix.

  Broadly, the tests were broken by #7489 because there were no _startupActions. They relied on the removed codepath that assumed wt.exe always set actions, or `AppCommandlineArgs::ValidateStartupCommands` created one by default.

  These tests are still broken:
  * `TerminalAppLocalTests::TabTests::TryZoomPane [Failed]`
  * `TerminalAppLocalTests::TabTests::MoveFocusFromZoomedPane [Failed]`
  * `TerminalAppLocalTests::TabTests::CloseZoomedPane [Failed]`

  Re:#9659

Broadly, the tests were broken by #7489 because there were no `_startupActions`. They relied on the removed codepath that assumed `wt.exe` always set actions, or `AppCommandlineArgs::ValidateStartupCommands` created one by default.

* [x] fixes #9659
* [x] I work here
* [x] the tests pass again

There are a couple places where we now bail immediately on startup, if we think the window is going to get created without any tabs. We do that to prevent a blank window from flashing on the screen when launching auto-elevate profiles. Unfortunately, those broke defterm in a particularly hard to debug way. In the defterm invocation, there actually aren't any tabs when the app completes initialization. We use the initialization to actually accept the defterm handoff. So what would happen is that the window would immediately close itself gracefully, never accepting the handoff.

In my defense, #8514, the original auto-elevated PR, predates defterm merging (906edf7) by a few months, so I totally forgot to test this when rolling it into the subsequent iterations of that PR.

* Related to: 
  * #7489
  * #12137 
  * #12205 
* [x] Closes #12267 
* [x] I work here
* [ ] No tests on this code unfortunately
* [x] Tested manually

Includes a semi-related code fix to #10922 to make that quieter. That is perpetually noisy, and when trying to debug defterm, you've only got about 30s to do that before it bails, so the `sxe eh` breaks in there are quite annoying.