[Feature] Pin the broker and runner images and put them, and the .NET benchmark arms, under Dependabot

[pathosDev]

Problem

#1596 put every package.json under Dependabot. Three other kinds of pinned
third-party version in the repository are still invisible to it, and two of
them are invisible by construction:

what	where	Dependabot ecosystem	why nothing moves today
the two .NET benchmark arms	benchmarks/comparison/{akka-net,orleans}/*.csproj + packages.lock.json (Akka 1.5.70, Orleans 10.2.2)	nuget	no entry
19 runner images	tests/integration/Dockerfile.node + 18 brokers/*/Dockerfile.runner, all FROM oven/bun:1.4-debian	docker	no entry — and the tag floats inside 1.4.x, so the tree does not say which image a run used
17 broker containers	image: in the 18 compose files under tests/integration/	docker-compose	16 of them are :latest (one is 2022-latest), which carries no version Dependabot could move; only MinIO is pinned (#1531)

The compose files argue for :latest explicitly — "integration tests want to
surface upstream regressions as soon as they ship, NOT whenever someone
remembers to bump a pin" — and that was the right call while remembering was
the only alternative. It has two costs the comment does not mention: the nightly
(integration-brokers.yml, 03:30 UTC) turns red underneath a run when a
broker ships a breaking release, with nothing in the tree to attribute it to,
and no run is reproducible after the fact — the compose file records
postgres:latest, not what that was. One of the sixteen is not even a release:
ghcr.io/tursodatabase/libsql-server:latest is a main-branch build
(org.opencontainers.image.version: latest, revision d6c75af6, built
2026-08-23), while the newest release tag is v0.24.33 (2025-12-19), so that
suite has been testing an unreleased server for months.

Proposed fix

Pin, and let Dependabot do the remembering. A new upstream release then
arrives as a PR that runs the suite it affects (the integration-brokers.yml
path filter already covers tests/integration/brokers/**), so a regression
surfaces within a day and is attributable to the bump — the goal of the old
comment, without its costs.

• Compose images → the release latest resolves to today, so the pin is
  provably what CI has been testing, not a guess. Resolved from the registries
  by digest (the version tag sharing the floating tag's manifest-list digest):
  rabbitmq:4.3.6, cassandra:5.0.9, cockroachdb/cockroach:v26.2.6,
  amazon/dynamodb-local:3.3.1, greenmail/standalone:2.1.14,
  rancher/k3s:v1.34.1-k3s1, redpandadata/redpanda:v26.2.3,
  mariadb:13.0.2, mongo:8.3.11, eclipse-mosquitto:2.1.2-alpine (the
  official image's latest is the alpine variant; no plain 2.1.2 tag
  exists), mcr.microsoft.com/mssql/server:2022-CU27-ubuntu-22.04,
  nats:2.15.0, postgres:18.6, redis:8.10.1,
  yugabytedb/yugabyte:2026.1.1.2-b9. The exception is libsql-server, pinned
  to the newest release, v0.24.33, rather than to the main build — the
  one pin that changes what is tested, deliberately. MinIO stays as it is
  (latest on quay is still the same digest as the pin).
• Runner images → digest-pinned: FROM oven/bun:1.4-debian@sha256:4f6e31d1…
  (the index digest, multi-arch, identical to 1.4.2-debian today — matching
  .bun-version). The Dockerfile.node policy ([Feature] Adopt Bun 1.4.0: pin the CI toolchain via .bun-version, bump Docker base images to oven/bun:1.4-debian, update docs (EN+DE) #1328) stays exactly as
  written: patch releases flow, the minor moves with .bun-version in one
  reviewed commit. The docker entry carries an ignore on major and minor
  for oven/bun, so what Dependabot moves is the digest — the 1.4.x rebuilds
  — and 1.5-debian is never proposed, the way @types/node majors are not
  (Dependabot re-proposes @types/node majors against the deliberate engines-floor pin (4th round: #481) #906). One catch-all group, so a rebuild is one PR across the 19 files
  rather than 19.
• nuget for the two .NET arms, with the Microsoft.Orleans.* pair grouped
  at every update type (the two move in lockstep, like github/codeql-action
  in Dependabot splits a codeql-action bump into one PR per sub-path, and each half fails CI by construction #1348) and a minor-and-patch group for the rest. Same re-measure rule as
  the JS arms: a merge here is a reason to re-run bench:compare before the
  tables are next updated.
• The guard in tests/unit/ci/WorkflowHygiene.test.ts generalises from
  package.json to every kind of manifest Dependabot can watch here:
  Dockerfiles, compose files and .csproj are each named by exactly one entry
  of the matching ecosystem; every integration FROM carries a digest; no
  compose image: is latest or *-latest.

Notes

• Dependabot cannot express two of the pins' formats, and that is fine:
  2022-CU27-ubuntu-22.04 (the cumulative-update number sits in what
  Dependabot treats as the suffix) and 2026.1.1.2-b9 (the build suffix
  changes per release) will not get proposals — the pin still states what was
  tested, and both move by hand like MinIO does. Everything else is
  X.Y.Z[-suffix] with a stable suffix, which it handles.
• The nightly schedule stays. Its comment currently says the run exists
  because "each suite tracks :latest"; what it still catches after this is
  the floating driver install in the runner images (the brokers manifest is
  installed unfrozen by design) and any flake, so the comment is reworded
  rather than the cron removed.
• Still not coverable, for the record: the four JVM arms (build.mill,
  .mill-version, the jvmId JDK pin — no Mill ecosystem), .bun-version,
  deno-version: v2.x, node-version: '24' (setup-action inputs),
  graphifyy==0.9.46 (a deliberate pin in a run: line; AGENTS.md says why).
• Verification here is registry-side only: every pin was resolved by digest
  and the digest of oven/bun:1.4-debian was confirmed to be the multi-arch
  index. The broker suites themselves cannot run on this machine (no Docker
  daemon), so the first integration-brokers.yml run on the branch is the
  proof that the pinned set is green — and the libsql pin is the one to watch.

Follows #1596.

[pathosDev]

First run, measured: the pins are green, and one grouping assumption was wrong

The pinned set is proven. integration-brokers.yml on the merge commit (02a69d3b, run 35479239376) is 18/18 green — including libsql on v0.24.33, the one pin that changed what is tested — and the two scheduled runs since are green too. docker-compose already did what it was added for: #1603 moved cockroachdb/cockroach v26.2.6 → v26.3.1 and rancher/k3s v1.34.1 → v1.37.0 as one grouped PR, and the matrix ran on it. The docker entry opened nothing, correctly: oven/bun:1.4-debian still resolves to the pinned index digest 4f6e31d1….

The Orleans grouping did not behave as documented. The body says the orleans group exists so the pair moves in one PR, on the documented rule that a dependency joins the first group it matches. On the first run the 10.2.2 → 10.2.3 bump opened twice: as the orleans group (#1607) and inside the minor-and-patch group (#1608, together with Akka) — and Dependabot closed #1607 as superseded once #1608 merged. Across directories: the precedence evidently does not hold. Harmless this time, but two PRs for one bump is exactly the shape the group was added to prevent, so the pair is now excluded from minor-and-patch explicitly (exclude-patterns), which does not depend on precedence at all. For a major the orleans group is still the only taker, so the lockstep property holds where it matters.