fix(interop): two ABI defects, struct field order and the announced API version

[Juliusz Kopczewski (julkiewicz)]

Two ABI defects in the interop, both of which compiled, loaded, passed the API hash check, and then crashed or
silently mis-dispatched at runtime. Found while checking the open item to repoint cef-version.json at our
published CEF build.

1. Struct field order

The generated structs mirror CEF's C API structs field for field, so their field order is ABI. The generator
emitted C++ declaration order. CEF's own translator emits version order: a member added by a later API version
is appended after every member of earlier versions, wherever its C++ declaration sits. That is what lets a client
built against an older version still find its members at the offsets it expects.

Where the two disagreed, a member landed mid-struct and shifted every member below it onto the wrong function
pointer. cef_browser_host_t was the worst case: release_accelerated_paint_surface sat 30 slots early, putting
send_key_event onward, through get_runtime_style, on the wrong entry. cef_command_line_t,
cef_download_item_t and cef_request_context_t were wrong the same way, and had been before we patched
anything: the trigger is any method carrying an added= annotation.

Fixed by sorting members by the version that added them, stably, so declaration order still decides within a
version.

2. The announced API version

A client announces its API version by calling cef_api_hash(version) before initializing, and the library then
builds its C API structs to match. Announce an explicit numbered version and every method added since is compiled
out of those structs, so a binding that knows about a newer method reads a different method's pointer, or reads
past the end.

The generator picked CEF_API_VERSION_LAST, so the bindings announced 15000 while being generated from the
experimental headers. ReleaseAcceleratedPaintSurface then jumped through whatever that field position holds in
a 15000-layout struct and took the process down with an access violation.

Fixed by announcing experimental, which is where CEF puts API not yet frozen into a numbered version, and so
where our additions live. It costs the compatibility across a range of CEF releases that an explicit version
buys, which is a fair trade while we ship the libcef we bind against.

Verification

Static: extracted the field order of all 130 generated structs and diffed each against the corresponding capi
struct in the CEF distribution we ship, resolving inherited bases and treating cef_base_ref_counted_t as the
opaque _base field the generator emits. Before: 4 mismatched. After: all 130 match.

Runtime: a managed harness now drives a real browser through these bindings against our patched libcef
(readym-cef, harness/glue). A 10 second run gives 368 accelerated paints, every one carrying a lease id,
every lease released through the managed binding, BGRA8888 at 1280x720, no software fallback, clean shutdown.
Reproducing either defect kills that run, so the check has teeth rather than merely passing.

Also here

The vendored CefGlue.Interop.Gen/include/ tree was still the 150.0.11 baseline and did not contain
ReleaseAcceleratedPaintSurface at all, so regeneration would have quietly deleted the hand-added binding.
Overlays the headers from the build we actually ship and regenerates from them.

cef_version deliberately stays an upstream release number: Directory.Packages.props pins
chromiumembeddedframework.runtime at $(CefVersion) and it is referenced unconditionally, so a value with no
published package fails restore on every platform. UPGRADE.md now explains why the two version fields
diverge, including the consequence that the Linux and macOS cef.runtime.* packages cannot be built from our
cef_build_version, which the CDN does not host.