chore: re-pin the thousandeyes corpus document to 7.0.102

[ShocOne]

main is red. The ThousandEyes vendor replaced the document the lock pinned, so the fetch stopped matching its hash and both tests reading it failed.

pinned  sha256:68e45bf31813  version 7.0.100  207 path(s) / 326 operation(s)
fetched sha256:b33faf23c39f  version 7.0.102  208 path(s) / 327 operation(s)

A clean vendor bump — one new path, one new operation. Same maintenance as #92 (7.0.99 → 7.0.100).

Rewritten by corpus.RewriteLock rather than by hand, so pinnedAt moves to the fetch time and the new bytes are materialised instead of an old cache being reused under a new hash. The tests assert len(doc.Paths) == pin.PathCount, so the counts move with the pin and nothing else needed touching.

Verification

Cold corpus cache, corpus tests forced to run rather than skip:

$ TFPFGEN_CORPUS_DIR=$(mktemp -d) TFPFGEN_CORPUS_REQUIRED=1 \
    go test -race -covermode=atomic -coverprofile=… ./internal/...
all packages pass

$ bash scripts/coverage_gate.sh    91.3% total, lowest package 85.0%
$ bash scripts/repo_hygiene_gate.sh   pass
$ golangci-lint run                0 issues
$ gofmt -l .                       clean

Both previously failing tests now pass: TestIntegration_Specmodel_LoadsAPinnedVendorDocument and TestIntegration_IntermediateRepresentation_DerivesAPinnedVendorDocument.

Worth deciding separately

This is the third ThousandEyes repin. thousandeyes.upstreamUrl tracks latest, so the pin goes stale whenever the vendor publishes — and it goes stale with no push, so main sat green in Actions while being red on a fresh checkout. The GitHub pin doesn't have this problem because #95 moved it to a commit sha; Cisco DevNet offers no equivalent immutable URL, so a mirror or a scheduled run is what would close it.

🤖 Generated with Claude Code