win: Add compatibility checking for chrome_elf + sandbox

[magreenblatt]

From #3935 (comment):

The bootstrap executable provides Chromium sandbox initialization and links chrome_elf.dll to support crash reporting and some DLL injection protections. This introduces dependencies on the specific Chromium version (e.g 136.0.7103.114). We must therefore check that the bootstrap and libcef.dll are using the same Chromium version during startup. We should also evaluate if it's possible to relax this check in the future (e.g. only match the major version instead of major + bugfix).

• The chrome_elf exports are listed in chrome/chrome_elf/chrome_elf_main.h. This appears to change infrequently and could potentially be tracked.
• Sandbox uses sandbox::SandboxInterfaceInfo and sandbox::policy::SandboxTypeFromCommandLine. This involves multiple C++ interfaces with relatively frequent changes (every few months). SandboxTypeFromCommandLine is less concerning as it will crash if passed an unrecognized flag.

[magreenblatt]

It may be sufficient to hash the contents of the following files (for simplicity, any change means not compatible):

• chrome/chrome_elf/chrome_elf_main.h
• sandbox/win/src/sandbox.h
• sandbox/win/src/sandbox_types.h
• out/Debug/gen/sandbox/policy/mojom/sandbox.mojom-data-view.h

[magreenblatt]

any change means not compatible

This would be Chromium binary compatibility independent of the CEF/Chromium version number. We would need some way to map this to a version number compatibility range for use by the shared installer (for example).

The mapping could work like this:

CDN metadata includes ABI hash per version:

  {
    "windows64": {                                                                                                           
      "versions": [
        {"version": "137.3.5", "abi_hash": "abc123", "file": "..."},
        {"version": "137.2.1", "abi_hash": "abc123", "file": "..."},
        {"version": "137.1.0", "abi_hash": "xyz789", "file": "..."}
      ]
    }
  }

Installer logic:

1. Filter by vmin/vmax (feature compatibility)
2. Filter by abi_hash match (binary compatibility)
3. Select newest from remaining

If no versions match both constraints:

• Fail with clear error: "No compatible CEF version found"
• This indicates a build/distribution error - app shipped a bootstrap incompatible with its declared version range

Build-time responsibility:

• App builder needs to ensure vmin/vmax covers versions with matching ABI hash
• Could be automated: build system queries CDN, finds versions with same ABI hash, sets vmin/vmax accordingly

Alternatively, simpler approach:

• ABI hash typically stable within a milestone (M137, M138, etc.)
• If ABI rarely changes mid-milestone, vmin/vmax based on milestone is usually sufficient
• ABI hash becomes a runtime safety check, not a primary constraint

[magreenblatt]

Related PR: #4097