Fix CI on main, and a mongo store bug it was hiding

[juicycleff]

Four CI failures on main, and one of them turned out to be a real bug in the mongo store rather than a build-hygiene problem.

The mongo store never keyed a pending ask correctly

Two conformance cases were failing, A2AClaimPendingAskConcurrency and A2AExpiredAsks, and they had one cause. The model tagged its key grove:"reply_with,pk" bson:"_id", and grove keys a document off its own column name, so the token never reached _id. Mongo assigned an ObjectID instead. Every claim by token found nothing, and listing expired asks failed trying to decode an ObjectID into a string.

Naming the grove column id, the way every other model in that file does, is the whole fix.

Why it reached main at all

The mongo backend had never been run. It cannot be, on a current machine: the pinned image refuses to start on a Linux kernel of 6.19 or newer, which is what Docker Desktop ships now.

ERROR: Detected Linux kernel 7.0.12-linuxkit. MongoDB has compatibility issues
with the allocator it uses on kernel v6.19 and newer, so this container will
not start by default on v6.19+.

The container exits 1 before mongod runs, so the suite never gets a database and every mongo test fails on container startup. CI's runner kernel is older and does not hit the guard, which is why the store's own tests looked fine while nothing had exercised them.

CORTEX_TEST_MONGO_IMAGE now overrides the pin, so the suite is runnable on a desktop:

CORTEX_TEST_MONGO_IMAGE=mongo:7 go test ./store/mongo/

CI keeps the pin. With the override, the whole mongo package passes, including all seven a2a cases.

Two tests hung instead of failing

TestEngineStartCarriesMessagesWithoutADrain and TestWorkersDeliverWithoutADrainCall waited on a channel with no timeout. When one of them did not get its signal, the package sat until Go's ten minute limit and reported nothing about which step never happened. Both waits are bounded now and say what they were waiting for.

The build hygiene, which is what the check was actually complaining about

Three requires named v0.0.0-00010101000000-000000000000, the placeholder go writes when a replace covers a module nobody has released. It builds locally because the replace answers first, and go get on any of them fails with "unknown revision". They name v1.6.1 now, which is what every other module in the tree names, and the replace still keeps local builds on the working copy.

The docs lint was failing on two counts. Biome's config named schema 2.4.1 while the lockfile pins the CLI at 2.4.3, and biome treats that mismatch as an error rather than a warning; biome migrate settles it. Two meta.json files had single-line page arrays the formatter wanted broken up.

The generated protobuf files were also not gofmt clean, because protoc-gen-go's import grouping is not what gofmt produces on this Go version. They are formatted, and generate.sh formats what it generates so regenerating will not bring it back.

Reconciling the versions with the module split

Main moved while this sat in review. The module split landed, fabriq 1.6.4 published, and testcontainers went to 0.44, and all of that collided with the grove and shield bumps this branch was carrying. Both go.mod files were merged by hand instead of taking one side: the root now runs grove 1.6.3 across all three drivers, shield 1.6.3 and go-utils 1.2.2, sitting on main's split layout and its newer testcontainers. The fabriq integration keeps main's wiring, because fabriq/core v1.6.4 is the published module that replaced the old local path.

Two go.sum files followed from that. extension was stale against main's testcontainers bump, and inttest picks up sqlitedriver 1.6.3 through its replace of the root module. That clears the Verify tidy failures on the api and extension sub-modules, which had been red since the split and were never caused by anything here.

That local replace is gone as well. The root go.mod carried replace github.com/xraph/fabriq/core => ../../../TwinOS/fabriq/core, pointing at a path that exists on exactly one machine. Nothing in the root module requires fabriq/core, so go was already ignoring the line, and taking it out changed go.sum by zero lines. With fabriq/core v1.6.4 published, it was residue from the split.

The runtime deps moved at the same time: weave 1.6.3, nexus 1.6.4, mongo-driver 2.8.2 and sqlite 1.58.0, with every sub-module tidied to match. extension would not build until that happened, because its go.sum had no entry for the new nexus.

Verification

go build ./... and go vet ./... across every module, and every module is tidy-clean. go test green on engine, a2a, a2aremote, grpcbind, postgres and sqlite, and on mongo under the override, all of it after the driver bumps. inttest vets under its integration tag. gofmt -l empty, golangci-lint clean, pnpm lint clean.