build: the tool is built with Go 1.27 now, and six formats change bytes

[donislawdev]

🔴 This is a breaking change under D11. It needs a major version bump, which is the owner's call and is not in this branch.

Raises the toolchain from 1.26.7 to 1.27.0 in go.mod and in both workflows, rewrites the pinned hashes that moved, and bumps two tools that cannot read Go 1.27 at all.

What changes for someone using the tool

Sizes are unchanged. Every size that worked still works, the same sizes are reachable, and every reader that took these files still takes them. What moved is the compressed data inside them.

different bytes	targz, png, docx, xlsx, pptx, ico when it holds a png, zip when compression is asked for
untouched	zip left alone (its default stores), and the other 17 formats, byte for byte
pinned cases that moved	11 of 51 generator cases, 7 of 7 standard library paths

Two minimums moved and the site says so: png 73 → 74 B (75-82 and 85 are now the unreachable band) and targz 1052 → 1049 B (next reachable 1051, gap at 1050). Measured with tools/probes/reachable-sizes.py rather than derived - two numbers in that table were once wrong precisely from being derived.

Why move at all

Not because 1.27 is better. This machine builds other projects already on it, and GOTOOLCHAIN belongs to the account rather than to a project, so the two kept taking it in turns - a byte guard went red on formats nobody had touched, and go version settled it rather than reading the diff. Staying meant a check before every command, forever. Decision by the owner; written up in docs/GO-127-MIGRATION.md and O169.

TAR.GZ could not be produced at all under 1.27

Every size was refused: the generator came out three bytes short of its plan. The size of a .tar.gz is arithmetic rather than a measurement - compressing twice to learn a length would make --dry-run cost what a run costs - and that arithmetic carried the gzip framing as constants. Go 1.27 changed one: the block that closes a level zero stream went from five bytes to two.

It measures the framing now, at first use, from four compressions, and checks the model against a third block and against the empty stream before trusting it. A later release can move these bytes again but can no longer stop the format from being written.

Two properties made this safe to land as one commit:

• The repair is byte neutral under 1.26.7 - nine of nine against a binary built from main. So every byte that moved in this branch belongs to the compiler, not to the repair, and the golden diff is auditable.
• The measurement costs nothing measurable - startup medians 93.5 ms against 93.3 ms with overlapping spreads over 12 interleaved runs.

Two tools had to move, and neither was a finding about this code

• staticcheck v0.7.0 → v0.8.1. The old one refuses the standard library outright: export data version 4 is greater than maximum supported version 2.
• govulncheck v1.1.4 → v1.7.0. The old one panics (panic: Int inside golang.org/x/tools), which reads like a security result on a gate named for vulnerabilities. The new one is clean and finds no vulnerability in 1.27.0 - worth knowing for a release with no patches behind it yet.

gofmt from 1.27 reindents exactly one file, internal/gui/window/generate.go, and that is included.

What was checked

• the full scope, finally countable because targz runs again: 11 of 51 and 7 of 7
• targz produced at every size tried, exact to the byte; 312 shapes through the arithmetic guard
• the framing repair byte neutral under the old compiler, 9 of 9
• the golden writer proven to round trip both files byte for byte before any hash was rewritten, so the diff is hashes and provenance and nothing else
• preflight non-test checks, 9 of 9, including the two new tool versions
• the broad guard set green; three mutation entries added for the framing, and ten mutations caught in total including three the change had staled

Full analysis, and what it got wrong before the work started, in docs/GO-127-MIGRATION.md.

🤖 Generated with Claude Code