Fix the release lane's member-count assertion before tagging v0.7.0

[snkmcb]

Blocks the v0.7.0 tag. Found while preparing to tag #132, before pushing
anything.

What would have happened

release.yml's staging step asserts the packaged member counts and exits
non-zero otherwise:

if [ "$bundles" -ne 4 ] || [ "$tools" -ne 2 ]; then
  echo "::error title=release packaging::expected 4 bundle + 2 tool packages, got $bundles + $tools" ; exit 1
fi

It has been 4 + 5 since v0.7.0. motion_bvh joined as a tool member, and
ost 0.22.2 widened tool discovery to reach
adapters/<group>/<name>/tools/<tool>/, which put mocopi_record and
vmc_record into the product without a descriptor in this repository changing
(ost report 35 §3).

Tagging against the old assertion would have failed the lane at the staging
step — after every build, both packaging runs and the digest-reproducibility
proof had already passed, on all three OS. This is the
hand-authored-release.yml trap exactly: a green PR
lane proves nothing about it, because no PR event runs it.

The fix

The expectation comes from the tree instead of from a constant:

want_bundles="$(find plugins -name openstrata.plugin.yaml -not -path '*/.strata/*' | wc -l | tr -d ' ')"
want_tools="$(find tools adapters -name openstrata.tool.yaml -not -path '*/.strata/*' | wc -l | tr -d ' ')"

.strata/ holds packaging copies of both descriptor kinds and must not be
counted. The assertion stays by member kind, so a tool silently dropping out
still fails and cannot be masked by a bundle count that adds up — and the next
discovery widening is reported here rather than arriving in a published archive.
The header comment stops naming the two tools it used to name and says why the
set is not a constant.

Verification

• Declared in the tree: 4 bundles, 5 tools
• ost plugin package --workspace --product: 4 bundles + 5 tools = 9 members,
  archives named …-0.7.0-<target>.tar.zst
• python -c "import yaml; yaml.safe_load(open('.github/workflows/release.yml'))" — parses
• scripts/clean_install_smoke.py --skip-build — PASS against the 0.7.0 packages
• A workflow_dispatch dry run of this branch — the real lane on real
  runners, creating no release object. Result reported in a comment below.

One note for whoever reads the local logs

ost plugin test plugins/usdVrmaFileFormat --from-package fails on this
workstation with three empty-message failures at L3/L4/L5, which is an
0xC0000005 in usdcat. It is stale local state, not a reader regression: the
package stages its sibling libraries from libs/<name>/build/<target>/, and
those trees here date to 2026-07-13 — six weeks and two releases before this
one — so a 0.7.0 plugin loads a July vrmContainer.dll. The build tree passes
the same pyramid 12/12, and a fresh checkout has no such directory. The dry run
above is what settles it for CI.

🤖 Generated with Claude Code