build(deps): tummycrypt_tinyvectors 0.3.5 -> 0.3.6 (registry latest)

[Jesssullivan]

deferred: lock

MODULE.bazel.lock is not updated in this PR and must be regenerated on a CI-capable seat before this can go green. This seat is the teletype machine and must not run bazel.

What moved

tinyland-inc/bazel-registry publishes 0.3.6 as the newest tummycrypt_tinyvectors module (modules/tummycrypt_tinyvectors/0.3.6/); this repo was pinned one behind at 0.3.5.

MODULE.bazel's own comment requires the Bazel version, the package.json tarball pin, and the prepare hook's PINNED_INTEGRITY to move in lockstep, so all three move here, plus the two lockfiles that record the pin:

file	change
MODULE.bazel	bazel_dep(tummycrypt_tinyvectors) 0.3.5 -> 0.3.6
package.json	tag archive pin v0.3.5.tar.gz -> v0.3.6.tar.gz
package-lock.json	root specifier + version / resolved / integrity
pnpm-lock.yaml	importer specifier+version, packages resolution+version, snapshot key
scripts/build-tinyvectors.mjs	PINNED_INTEGRITY url + registry SRI

The v0.3.6 tag exists upstream (tinyland-inc/tinyvectors) even though gh release list shows v0.3.4 as the latest release — v0.3.5 and v0.3.6 are tags without release objects, which is the same shape the currently-committed v0.3.5 pin already relies on.

Why the lockfile edits are safe to hand-derive

The upstream diff between the v0.3.5 and v0.3.6 tag archives is the package.json version field alone. dependencies, peerDependencies (svelte >=5.20.0), engines (node >=22.0.0) and license (Zlib) are unchanged, so the npm/pnpm resolution graph is unchanged and both lockfile edits are a pure pin swap.

Integrity provenance — no package manager was run on this seat:

• the registry's 0.3.6/source.json records sha256-IbKMSlUQR3g3Elf4ks2ViCEdCxtwlBrdBx8wegiX8zg=
• downloading the v0.3.6 tag archive and hashing it reproduces that sha256 exactly; the sha512 over those same verified bytes is what is written to package-lock.json
• the method is validated against the repo's own committed state: the identical download-and-hash procedure applied to v0.3.5 reproduces the sha512-BA8vm6sf... already committed for 0.3.5, byte for byte

CI's npm ci is still the oracle here — it re-fetches and re-verifies the tarball against the recorded integrity.

What CI will do with this as-is

.bazelrc sets common:ci --lockfile_mode=error, and MODULE.bazel.lock pins registryFileHashes for the 0.3.5 MODULE.bazel and source.json only:

.../modules/tummycrypt_tinyvectors/0.3.5/MODULE.bazel
.../modules/tummycrypt_tinyvectors/0.3.5/source.json

So every Bazel lane will fail on the stale lock until it is regenerated. The npm-rail lanes should be unaffected.

Follow-up on a CI-capable seat: regenerate MODULE.bazel.lock (bazel mod deps / any bazel build with the default --lockfile_mode=update) and push the resulting two-line registryFileHashes swap onto this branch.

Note the lock's moduleExtensions section does not record pnpm-lock.yaml as an input (the %npm extension is absent; only %pnpm is recorded), so the pnpm-lock edit here does not itself widen the regeneration.

Adjacent, not done here

.bazelrc pins the registry at the mutable branch ref https://raw.githubusercontent.com/tinyland-inc/bazel-registry/main rather than an exact SHA. That is a separate supply-chain change with its own ceremony (re-reading the registry's .bazelversion at the newly pinned SHA in the same commit) and is deliberately out of scope for this bump.