Say what the build and vet jobs covered instead of passing in silence

[iderex]

Refs #62

What this changes

The six build entries and the vet job print what they covered. Each build entry
prints how many packages it compiled and refuses a run that compiled none. The
vet job prints the same count and carries no zero-check, for a measured reason
given below.

What failure it prevents

Both jobs printed nothing at all on success, so their whole output was a tick.
A tick that says nothing reads the same whether the pattern reached the runner
or reached nothing, and the second case is green rather than red:

go build ./docs/...
go: warning: "./docs/..." matched no packages
(exit 0)

That is a pattern somebody narrows by hand, not a directory that is missing.
The toolchain already refuses the missing directory, so the guard is written
against the mistake that is actually available.

go vet answers the same pattern differently, which is why the two steps are
not symmetric:

go vet ./docs/...
go: warning: "./docs/..." matched no packages
no packages to vet
(exit 1)

A zero-check in the vet job could not fail for the reason it would name, so it
is not there and the comment at the step says so.

What was run

At the commit being pushed, 37ec738e482cb7a0a2b56cc46971b07e1c0dfb83.

The build step as written, with the pattern it carries and then with the
pattern narrowed to a directory holding no packages:

set -euo pipefail
go build ./cmd/... ./internal/...
compiled=$(go list ./cmd/... ./internal/... | wc -l)
echo "linux/amd64: compiled ${compiled} package(s) of the runner"
if [ "$compiled" -eq 0 ]; then
  echo "::error::This entry reported success having compiled nothing."
  exit 1
fi

linux/amd64: compiled 7 package(s) of the runner
(exit 0)

set -euo pipefail
go build ./docs/...
compiled=$(go list ./docs/... | wc -l)
...

go: warning: "./docs/..." matched no packages
go: warning: "./docs/..." matched no packages
linux/amd64: compiled 0 package(s) of the runner
::error::This entry reported success having compiled nothing.
(exit 1)

So the guard bites, and it bites on a step that would otherwise have been
green. The four commands the guide asks for, at this commit:

go build ./cmd/... ./internal/...
(no output)
go vet ./cmd/... ./internal/...
(no output)
gofmt -l cmd internal
(no output, exit 0)
go test -count=1 -v ./cmd/... ./internal/...
ok      github.com/Flowfin/lab/cmd/lab  1.441s
ok      github.com/Flowfin/lab/cmd/pullrequest  1.937s
ok      github.com/Flowfin/lab/internal/check   1.296s
ok      github.com/Flowfin/lab/internal/hardware        1.226s
ok      github.com/Flowfin/lab/internal/invariants      1.809s
ok      github.com/Flowfin/lab/internal/prose   1.301s
ok      github.com/Flowfin/lab/internal/pullrequest     1.474s

93 top-level tests executed, none skipped. No Go source changed here, so the
suite is unchanged by it and is run because the commit being pushed is what a
claim is made about.

go run ./cmd/lab check .
examined .
1 experiment directory walked, 1 record read
18 decision records read
the time this run read is 2026-08-12T06:17:43Z
0 refused

What this does not do

This does not finish #62. That issue asks for a comparison against the required
set on the default branch, and the set is empty, so there is nothing for the
clause to be evaluated against yet. The fork route it also asks for has not
been walked.

It touches two jobs and not the rest. The other jobs whose contexts the parity
document keeps already print a count, a report or a sentence. The formatting
job is the weakest of those: it prints that every Go file the runner is built
from is formatted, without saying how many it read, and that is left as it is
rather than changed here.

It adds no refusal to the suite. The zero-check is a step in a workflow, proved
by running the step both ways above rather than by a test in the tree.

Nobody else has read this change. What stands behind it is the evidence above
rather than a second reader.