Summary of the issue:

AMD64 builds of NvDA are not currently functioning on ARM64 devices such as Copilot PC.
NVDA seems to crash when initializing NVDAHelper.
The crash seems to occur when trying to set the first nvdaControllerInternal function pointer for nvdaHelperLocal.dll in NVDAHelper.initialize. Yet all the previous function pointers for nvdaController are set correctly.

With the merging of pr #18570, for performance improvements NVDA loads ARM64EC dlls for AMD64 processes when running on ARM64. If NVDA itself is build as AMD64, this will include nvdahelperLocal.dll. There may be some kind of ARM64EC to AMD64 thunking issue going on here between nvdaHelperLocal.dll and Python ctypes callbacks. Though only specific to nvdaControllerInternal, not nvdaController.
Interestingly, nvdaController is c++, but nvdaControllerInternal is only c. Perhaps the compiler / headers only manage thunking for c++. Noting that with ARM64EC, I believe functions may get multiple entry points depending on whether being called with ARM64 or AMD64 code to appropriately handle arguments.
Description of user facing changes:

AMD64 builds of NVDA will run correctly on ARM64 devices such as Copilot PC.
Description of developer facing changes:
Description of development approach:

    Rename nvdaHelperLocal's nvdaControllerInternal.c to nvdaControllerInternal.cpp, now compiling with C++.
    nvdaHelper.initialize: rewrite the code that chooses which NVDA Helper Remote Loader processes to start, to be more accurate and readable. The logic now groups by specific OS archetecture, making it very clear which ones apply to which OS archetecture. This rewrite also ensures that particular checks are no longer skipped if an earlier check succeeded. E.g. previously ARM64 remote loader was never started on ARM64 if NVDA was compiled as AMD64.