Re-pin to ost 0.22.8, and close PKG-4 and PKG-5 on the measurement

[snkmcb]

Two things, in that order: the ost pin moves to 0.22.8, and PKG-4/PKG-5 close
on the measurement that #150
could not carry because its lane had not run yet.

Closes #113.

The re-pin changes nothing here, and that is the finding

0.22.8 is current, so the contract takes it. What it does not do is close
anything, and that is on record rather than left to be assumed:

• Re-pulling a pinned leaf leaves its CMake package byte-identical. Same
  MD5s for pxrConfig.cmake and cmake/pxrTargets.cmake as under 0.22.6, and
  the producer's Python include directory is still on sixteen imported targets.
  Report 37's
  P1 is in what was exported, so only a republished runtime can move it.
• ost ci generate renders no semantic change. The whole regeneration diff
  is the version string, in three places per job.
• runtime validate is fully green on a workstation under 0.22.8,
  openusd-render included, which 0.22.6 skipped there.

One measurement from that worth reading: runtime validate has a
consumer-configure check — find_package(pxr) configures against
<runtime> — and it passed on the Linux runner, on the same runtime the
consumer lane could not link against. It is presumably configure-only, since a
probe that linked an imported target would have hit the same wall. It is not a
substitute for this lane, and reading it as one is the same mistake as reading
the workspace cell's green as evidence.

PKG-4 and PKG-5 close by measurement

The lane is green on windows-2022, macos-15 and ubuntu-24.04 — twelve
packages each — and criterion 6 is met:

• every workspace target in every closure is present on all three platforms or
  on none;
• the one difference PACKAGE_CONTRACT.md permits is present in both
  directions — Threads::Threads on macOS and Linux, ws2_32 on Windows, for
  liveTransport and each of the three adapters that inherit it.

That second line is #113's raw-library half, open since the mocopi receiver grew
a platform link: on both POSIX platforms vrmAdapterMocopi links the threading
library and no socket one, which is the absence no Windows run can see. The
carried roadmap entry goes with it, because the roadmap holds work that is not
finished.

Every Standalone cell in PACKAGE_CONTRACT.md §4 is now unqualified. The four
that read measured (Windows) were liveTransport and the three adapters;
nothing about their packages changed — a second and third host looked.

Two things the run said that the plan had not

The repair fires on two platforms, not three. macOS's baked paths resolve on
macos-15, so it repaired nothing and derived nothing — neither workaround
has ever been exercised there. That is a latent gap, not a passing grade: if
that leaf is republished from a machine whose paths do not resolve on a runner,
macOS fails with nothing to fall back on. It is left measured-and-stated rather
than fixed, because fixing a sysconfig derivation for a host this project
cannot run is guesswork — and the lane prints the gap on every run.

The synthetic verification had the right shape and the wrong counts. The
criterion-6 comparison's ten cases were checked against predicted POSIX
closures, and #150 said in advance that this was a prediction. Measured:
OpenUSD's platform link line is three entries on Windows (Dbghelp.lib,
Shlwapi.lib, Ws2_32.lib), two on Linux (dl, m) and three on macOS
(those two plus -framework Foundation) — 10 external entries against 9 and 9,
where the prediction had 10 against 10. The rules fired where they were aimed;
what they would see was approximate.

What is still not known

Why workspace-pr-linux is green on a runner where this lane measures
/usr/include/python3.13 missing. Three explanations were tested and
eliminated — the toolchain file, the Ninja generator, and a repair inside
ost build (which fails against a foreign path exactly as a plain cmake
does). Report 37 records it as unexplained rather than guessing, and the lane
now prints the underlying fact on every run.

🤖 Generated with Claude Code