Add Tailwind CSS v4 support with backward-compatible v3 auto-detection

[franchb]

Closes #101

Summary

Adds full Tailwind CSS v4 support to htmgo while maintaining zero-breakage backward compatibility for existing v3 projects.

Key behaviors:

• Existing v3 projects: auto-detected from @tailwind directives in input.css, pinned to v3.4.16. No user action needed.
• New projects: default to latest Tailwind (v4). Templates ship with v4 CSS-first config.
• Explicit override: users can set tailwind_version: v3.4.16 (or any version) in htmgo.yml.

Changes by area

1. Framework config (framework/config/project.go, 1 line)

• Add TailwindVersion string field to ProjectConfig
• Tests for config parsing added to project_test.go

2. CLI: version resolution + caching (new cli/htmgo/internal/tailwind/ package)

• version.go: DetectTailwindVersion() (config > input.css auto-detect > "latest"), IsV4(), DownloadURL()
• cache.go: sidecar __htmgo/tailwind.version file for cache invalidation when configured version changes
• 22 tests covering all branches and edge cases

3. CLI: download + invocation (cli/htmgo/tasks/)

• css/css.go: version-aware binary download URL, v4 CLI invocation omits -c ./tailwind.config.js flag, v4 projects don't require tailwind.config.js to exist
• copyassets/bundle.go: skip tailwind.config.js copy for v4 projects

4. Template + example migration

• All input.css files: @tailwind base/components/utilities → @import "tailwindcss"
• All tailwind.config.js files deleted (v4 uses CSS-first config)
• hackernews, htmgo-site: @plugin "@tailwindcss/typography" (v4 standalone CLI bundles first-party plugins)
• todo-list: 19 custom theme colors migrated from JS theme.extend.colors to CSS @theme { --color-*: ... } variables

Backward compatibility

The auto-detection logic ensures no breakage:

1. If htmgo.yml has explicit tailwind_version, that takes precedence
2. If input.css contains @tailwind (with trailing space — avoids false match on @tailwindcss), version resolves to v3.4.16
3. Only if neither condition is met does it default to latest (v4)

Note on go.mod

The TailwindVersion field lives in the framework module, which the cli/htmgo module depends on. A replace directive is included so the CLI can reference the local framework during development. After merge to master, the existing update-framework-dep.yml workflow will automatically run go get to update cli/htmgo/go.mod to the new framework commit, at which point the replace directive can be removed.

Test plan

• cd framework && go test ./... — all pass
• cd cli/htmgo && go test ./... — 22 new tests + existing all pass
• htmgo-site builds and serves correctly with Tailwind v4.2.2 (verified with Playwright — 0 console errors)
• Manual: create new project with htmgo template — should use v4
• Manual: existing v3 project with @tailwind directives — should auto-detect v3

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 69.91%. Comparing base (5d9c2f8) to head (a7956a3).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #103      +/-   ##
==========================================
+ Coverage   69.63%   69.91%   +0.27%     
==========================================
  Files          36       36              
  Lines        3188     2599     -589     
==========================================
- Hits         2220     1817     -403     
+ Misses        919      733     -186     
  Partials       49       49              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.