…lows the engine (#361)

* feat(ggml-org.llamacpp): b10069.1 and b10069.2, and a CI pin that follows the engine

`b10069.1` adds `backend-vulkan`: llama.cpp's Vulkan backend as build-graph
edges, 134 vendored shaders compiled by declared actions rather than by a build
program looping. `b10069.2` refuses a libc++ toolchain by name -- upstream's
ggml-vulkan.cpp destroys a `std::unique_ptr` to an incomplete type, which libc++
rejects by static assertion and libstdc++ accepts. Both mirrors byte-identical
(1456b6003dada314..., 36027267 bytes).

The CI pin moves 2026.8.27.2 -> 2026.9.6.3. It had drifted about ten releases
behind, so this index was validated against an engine no user runs. These
entries made the drift visible rather than causing it: their build program calls
`mcpp::toolchain_sysroot()` and `mcpp::toolchain_binutils_dir()` (2026.9.5.2+)
to hand the ecosystem C library to the second compiler it drives, and
`mcpp::cxx_stdlib()` (2026.9.6.3) to make the refusal above possible. Under the
old pin the workspace members could not compile it at all.

The cost is paid once per move and it is large: the members' caches key on
`MCPP_VERSION`, so this run rebuilds every member on every platform -- measured
on the previous attempt at twelve shards still cold after fifty minutes. Both
revisions therefore land in ONE pin move rather than two, which is also why the
`mcpp:plugins` 0.2.1 entry went separately in #360: it needed no pin change, so
`select` picked nothing for it.

`index.toml` min_mcpp does not move. It states the oldest mcpp able to RESOLVE
every descriptor, and all of them parse under both versions; raising it would
refuse the whole index to a client on the floor over a build-program API that
client may never reach. `b10069` stays published for exactly that case.

* ci: raise the shard caps that cancelled three jobs at 90 minutes

The caps were the binding constraint again and the measured table has grown
about 50% since they were set. `plan_shards.lua` on this tree reports linux
23925s, macos 16676s, windows 18435s, so `secs / 4200 + 1` asks for 6 / 4 / 5
while the caps clamped to 4 / 2 / 2. Windows at 18435s over two shards is
roughly 150 minutes a shard, over the 90-minute job cap before a cold cache is
considered at all.

Observed rather than predicted. On this PR's pin move three shards were
cancelled at exactly 90 minutes: `linux default 0/4`, `linux default 3/4` and
`windows default 0/2`. The two linux shards passed on a re-run against the warm
registry cache. The Windows one timed out AGAIN at 1h30m13s WITH the cache
restored -- the pin change invalidates every member build, and that shard
carries godot-cpp-m twice (9.5 and 10 minutes) plus opencv.

linux 4 -> 6, windows 2 -> 5. macos stays at 2: it has never been cancelled, so
raising it would be a prediction rather than a measurement, and the formula's 4
is there the day it is. The paragraph that set the previous caps is marked
superseded rather than deleted, because it records the measurement that was
true when it was written.

* ci: the llvm leg needs its own shard count

`plan_shards.lua` takes a PLATFORM and reads one timing table. It has no
toolchain dimension, so `linux default` and `linux llvm` were handed an
identical split of an identical estimate -- and they are not identical work.
The llvm leg resolves a different compiler with no sysroot, and it is the
slower of the two.

Measured on this PR, with both legs at 6 shards: every `linux default` shard
finished, and `linux llvm 5/6` was cancelled at 1h30m16s. The split was right
for the leg the table was measured on and wrong for the other one.

`lln = ln + 3` is the smallest correct fix. Teaching the planner about
toolchains is the larger one and needs a timing table per leg, which CI does
not produce yet.