Import the landing kit as a Hugo module instead of copying it

[tannevaled]

The design partials now come from the Hugo module go-fleettools/landingkit v0.1.0 instead of copies here. The copies were byte-identical to the module's (styles.html md5 750222ab…, and the same for the other five files), and copies drift: six landings already carry a variant stylesheet.

What changes

• hugo.toml: [module] [[module.imports]] path = "github.com/go-fleettools/landingkit", with a comment.
• go.mod / go.sum: pin github.com/go-fleettools/landingkit v0.1.0. Hugo resolves modules with the go command, and Renovate will propose the bumps.
• kit.go: a //go:build tools file that imports the module and never builds. Without it, go mod tidy deletes the requirement because no Go code uses it; I measured this on landingkit's example. The org's Renovate preset runs gomodTidy after every update, and the grouped branch auto-merges, so the first bump would have removed the module.
• Deleted: layouts/partials/{styles,theme-toggle,fork-ribbon}.html, icons/{github,book}.html, icons/OCTICONS-LICENSE (the licence ships with the module).
• Kept: icons/play.html, which is this site's own. Site partials still take precedence over the module's.
• Workflows: ci.yml, links.yml now run actions/setup-go (go-version-file: go.mod) before Hugo, in the jobs that had no Go.

Proof: the built site is byte-identical

I built fresh clones of main and of this pushed branch (based on current main) the way the workflows do, then ran diff -r on the output:

build	files	result
hugo 0.167.0	5	identical
hugo --minify 0.167.0 (ci, links)	5	identical
hugo --gc --minify --baseURL … 0.135.0 (deploy)	5	identical

Negative control (run on go-widgets, same change): with the partials deleted and the [module] import removed, the build fails. With the import, it is identical to main. So the module really is where the partials now come from. hugo mod graph shows github.com/go-fleettools/landingkit@v0.1.0.

The playground

playground/ is a nested Go module with its own go.mod, so the new root go.mod does not include it, and none of its files change. On this branch it still vets, its tests pass, and the js/wasm build succeeds. With VCS stamping off (-buildvcs=false), the wasm built on this branch is byte-identical to the one built on main. With stamping on, they differ only by vcs.modified on my uncommitted working tree, which proves nothing either way. hugo.yml and playground.yml already set up Go.

🤖 Generated with Claude Code