Adopt the Evergine.Bindings toolbox

[jcant0n]

Moves this repository onto the fleet's current infrastructure. It was built following
C2CSharpBinding.agent.md, which points at evergine-standards@v2 — the previous location.
Meshoptimizer and the other tracked bindings already consume
Evergine.Bindings@v1.

binding.yml

The manifest both the deterministic and the agentic workflows read. Validates against
binding.schema.json. kind: git-tree, tracking stable releases of RenderKit/embree, with
current: v4.4.1 — the one place the version lives, rewritten by binding-fetch-upstream when
a newer release arrives.

Its NOTE comments record the two hazards specific to this repository, because the
binding-updater agent reads and obeys them:

1. rtcore_config.h is not an upstream source. Embree's CMake generates it, and it decides
   the layout of several public structs — RTC_MAX_INSTANCE_LEVEL_COUNT sizes the instID
   arrays, RTC_GEOMETRY_INSTANCE_ARRAY adds the instPrimID ones, RTC_MIN_WIDTH adds a
   field to RTCIntersectArguments. It comes from embree-cmake.yml alongside the binaries.
   Refreshing the header tree leaves it alone: the git-tree adapter only writes what it
   fetched.
2. Headers and native binaries cannot move independently. P/Invoke binds late, so a
   mismatched package compiles, passes CI, publishes, and only then throws.

CD becomes three jobs

resolve → natives → cd, matching Meshoptimizer:

• binding-resolve-upstream settles on one release and nothing else decides it.
• embree-cmake.yml builds the natives at that release. It gains workflow_call for this,
  and its artifacts now carry their final repository paths so the CD unpacks them over the
  tree.
• binding-tracked-cd regenerates, packs and publishes, taking the natives by artifact
  pattern — but only when the natives job actually ran, since asking for artifacts that were
  never produced fails the download.

natives is gated on ref_moved: four platform builds, the x64 legs alone about an hour, is
not something to spend on a maybe.

One detail worth a look: rtcore_config.h is collected from the linux-x64 leg only. Every
leg generates a byte-identical file, but the Windows one is written with CRLF, so letting all
four contribute would flip the committed header's line endings depending on unpack order.

Generation stays on Linux

MeshOptimizer, RenderDoc and KTX all generate on windows-latest because the libclang in the
CppAst package carries no system include paths and none of its own builtin headers, so
<stddef.h> does not resolve on Linux. This generator parses against the stubs in
EmbreeGen/Headers/stubs with a pinned x86_64 target, so it does not have that problem — and
as a side effect its output is identical on any host. Please don't "fix" it onto Windows; there
is a comment in binding.yml saying so.

Not in this PR

The agentic workflows (binding-updater and friends) and toolbox-update.yml — block B of the
roadmap. That needs vars.APP_CLIENT_ID / secrets.APP_PRIVATE_KEY at the org level and a set
of agent:* labels on the repository, so it is worth its own change.