ci: read the provider's drift paths from its build graph

[rldyourmnd]

config/provider-derivative.yaml promises that binary_sha256 is what this tree builds, and two jobs enforce it — one decides whether the provider changed at all, the other refuses a release whose source commit no longer matches HEAD. Both asked a hand-written list of directories.

That list named eight packages. go list -deps ./cmd/garm-provider-incus-nddev reports eighteen. Missing, among others:

internal/cachebroker      internal/queueintent
internal/telemetryattrs   internal/fleettrace
internal/admission        internal/tenant
internal/pressuregate     internal/hostprobe
internal/incuspolicy      internal/workerdiagnostics

Both cachebroker and queueintent are real provider dependencies, so a change to either skipped the reproducible-build job entirely and shipped under a manifest digest that no longer described main. That is how v0.1.5-nddev.95 came to be stamped against a commit whose provider bytes main no longer produces — building the released source gives f7a76eaf…, building main gives ba2df150…, and nothing said so. I found it by building the release locally before deploying it.

The fix. scripts/provider-package-directories.sh reads the set from the same graph the compiler walks, so it cannot fall behind a new import. Both jobs consume it. A _test.go file is still ignored; go.mod/go.sum still count.

The contract test was part of the problem. It asserted that five path strings appeared somewhere in ci.yml — which stayed green the whole time the list was missing ten packages. It now runs the same script and asserts the boundary itself: every package the binary links, never the observer-only internal/providerretry. A second test holds the workflow to actually consulting it, since a boundary nothing reads classifies every change as provider=false.

v0.1.5-nddev.96 stamps main, so the deployed provider matches a manifest again.