Deploy docs site with Hugo via GitHub Actions

[oschwald]

Summary

Migrates the Pages index from Jekyll on gh-pages to a Hugo build that
publishes back onto gh-pages from GitHub Actions. All CSS is now
inlined in the layout template — no external CDN dependencies.

• Hugo site lives under docs/ on main and mounts README.md as
  the home page; the source of truth stays in one place
• A small pill nav links from the overview to the Javadoc at
  /doc/latest/
• .github/workflows/pages.yml builds with mise run build-docs and
  pushes to gh-pages via peaceiris/actions-gh-pages with
  keep_files: true, so every /doc/vX.Y.Z/ Javadoc subtree stays
  untouched
• dev-bin/release.sh no longer regenerates the Jekyll index.md;
  the Javadoc-publishing block that writes doc/$tag/ and updates
  doc/latest is unchanged

Same design as MaxMind-DB PR #221: Charter serif body text,
forest-green accents, hover # anchor links.

Preview locally with mise run serve-docs.

For STF-448.

Post-merge steps

1. Verify the live site at https://maxmind.github.io/GeoIP2-java/ and
   a sample https://maxmind.github.io/GeoIP2-java/doc/latest/ still
   loads after the next workflow run
2. After we're confident the Hugo-rendered index is healthy, drop the
   legacy Jekyll source (_config.yml, _layouts/, the
   release-generated index.md, stylesheets/pygments.css,
   Gemfile*) from the gh-pages branch in a separate commit

Pages source stays on gh-pages — no Terraform change for this repo.

Test plan

• mise run build-docs succeeds with no warnings
• Rendered <title>, <h1>, and pill nav are correct
• No static-gh.maxmind.com references in the new site
• Build job passes in CI (push step only runs on main)
• After merge, confirm the workflow pushes successfully to gh-pages
  and /doc/vX.Y.Z/ subtrees are preserved

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request transitions the project's documentation generation from a manual script to Hugo, introducing a new Hugo configuration, layouts, and mise tasks for building and serving the site. The review feedback suggests enhancing the robustness of the HTML templates by handling potential null file objects in the page title and using absolute URLs for links to external API documentation. Additionally, it is recommended to pin the Hugo version in the mise configuration rather than using the 'latest' tag to ensure environment consistency.

[gemini-code-assist]

The fallback logic or .Title .File.BaseFileName might fail if .File is nil, which can happen for certain virtual pages in Hugo. While all current pages are file-backed, it's safer to use the with statement or check for .File existence to avoid potential build errors in the future.

Suggested change

	<title>{{ if .IsHome }}{{ .Site.Title }}{{ else }}{{ or .Title .File.BaseFileName }} | {{ .Site.Title }}{{ end }}</title>
	<title>{{ if .IsHome }}{{ .Site.Title }}{{ else }}{{ with .Title }}{{ . }}{{ else }}{{ with .File }}{{ .BaseFileName }}{{ end }}{{ end }} | {{ .Site.Title }}{{ end }}</title>

[gemini-code-assist]

Using relURL for a path that is not managed by Hugo (the Javadocs are generated by Maven and pushed directly to gh-pages) might lead to incorrect links if the baseURL in hugo.toml is not perfectly aligned with the deployment environment. Since the Javadocs are at a known path relative to the site root, using absURL or ensuring the path starts with a leading slash (if baseURL includes the subpath) is often more robust.

Suggested change

	<a href="{{ "doc/latest/" | relURL }}">API documentation</a>
	<a href="{{ "/doc/latest/" | absURL }}">API documentation</a>

[gemini-code-assist]

While mise.lock pins the version, it is generally better practice to specify a version range or a minimum version in mise.toml instead of latest. This provides better visibility into the required tool version without needing to inspect the lockfile.

Suggested change

	hugo = "latest"
	hugo = "0.161"