v0.1.1

A bug fix. v0.1.0 could not read go vet output at all.

Fixed

go vet errors were invisible. go vet prefixes its diagnostics with
vet: , and the position matcher is anchored to the first token on a line,
so nothing matched and nothing was ever recalled — silently, with no error
anywhere to show for it.

This mattered more than it looks. The reason a command's subcommand is not
part of a fingerprint is precisely so that one error is one memory across
go build, go test, go run and go vet. That promise was only three
quarters true.

A fix recorded while running go build is now found when go vet reports
the same thing:

$ forgelore recall --command "go vet ./..." --error-file err.txt
1 error(s), 1 with something recorded

cd023fb609411574  undefined: greet
  fix       01M45W8AM40B94WTEANTXK4BX5  greet lives in internal/greeter; import it

The error corpus gained go/vet-undefined, captured from a real run, and
the test that checks two errors never collide now also insists that these two
families do share a fingerprint. They were captured on different operating
systems, so it proves the fingerprint survives the OS, the path shape, the
line number and the subcommand at once.

scripts/capture-errors.sh wrote the wrong platform. The frontmatter
field was hard-coded to windows/amd64; it now comes from the machine that
captured the file.

Upgrading

curl -fsSL https://raw.githubusercontent.com/forgeprint/forgelore/main/scripts/install.sh | bash

Nothing to migrate. Records written by v0.1.0 are read unchanged, and any
fingerprint recorded then is still correct — v0.1.0 simply never produced
one from go vet.