ci: add the gem's CI workflow + the missing generator specs

[mhenrixon]

Closes #23. Part of #8 (Phase 5) — the CI gate every other issue in the epic merges through.

What this does

The gem repo had no CI: bundle exec rake (rspec + rubocop) was trust-based on every PR, and CLAUDE.md's claim that "Generator specs cover docs_kit:install output" was false — spec/generators/ did not exist. This wires real CI + real generator specs and makes the docs true.

CI — .github/workflows/ci.yml

• Runs on push to main and all PRs.
• Matrix: Ruby 3.2 / 3.3 / 3.4 (matches the gemspec's >= 3.2).
• ruby/setup-ruby with bundler-cache: true, then bundle exec rake.
• Concurrency-cancel superseded runs on the same ref.
• One job — the generator specs invoke the install generator via plain Thor against a tmp app skeleton (no Rails boot), so they need no heavier harness than the rest of the suite.

Generator specs — spec/generators/install_generator_spec.rb

14 examples. Each builds a minimal fake-app skeleton (routes.rb, application_controller.rb, controllers/index.js, assets.rb) in a throwaway destination root, runs the generator, and asserts:

• the full file manifest (initializers, registry model, controllers, pages, CSS build, keeps);
• c.brand / c.title_suffix substituted from the humanized app name;
• the theme list in the initializer matches the Tailwind @plugin block;
• the docs + root route injection;
• include DocsKit::Controller injected into ApplicationController (and skipped when absent);
• the builds asset path appended to assets.rb;
• the package.json stub scripts (and that an existing package.json with build:css is left untouched);
• the docs_kit/controllers Stimulus registration (and skipped when there's no index.js);
• bin/build-css created executable (chmod 0755).

These assert current behavior. I verified the generator is largely idempotent (Thor's route / inject_into_file guard against duplicate lines; several steps say_status(:skip) on an existing target) — the issue's assumption that add_routes blind-appends is stale, so there's no idempotency bug to file. create_initializer re-renders on every run, which is fine.

Coverage gate

SimpleCov in spec/spec_helper.rb with minimum_coverage 80 — the 80% floor documented in CLAUDE.md is now enforced (the suite fails below it, locally and in CI). Current line coverage: 86.76%.

Incidental fixes (CI-blocking, pre-existing)

bundle exec rubocop already crashed on clean main (verified by stashing my changes) — it descended into the tracked docs/ dogfood site, whose .rubocop.yml inherits rubocop-rails-omakase (not in the gem's bundle), and into agent scratch worktrees. Without fixing this, CI's rake can never go green. Fixes:

• Excluded docs/, .claude/, coverage/, tmp/ in .rubocop.yml (the docs/ site lints itself with its own bundle).
• Guarded the daisyui path override in the Gemfile (if File.directory?(...)) so CI / a fresh clone without the sibling checkout resolves daisyui from rubygems via the gemspec dependency.
• Ignored .claude/worktrees/.

Docs

• CLAUDE.md + .claude/rules/testing.md: the generator-specs claim is now true; documented the SimpleCov enforcement and the CI matrix.
• README: added a CI badge.

Test plan

• bundle exec rake green locally — 75 examples, 0 failures, 86.76% line coverage, rubocop clean (39 files, 0 offenses).
• SimpleCov gate proven: flipping a spec assertion goes RED; coverage below 80 fails the suite.
• This PR's CI check runs green on all three Rubies (watch the Actions tab).
• Manual, post-merge: make CI a required check on main in repo settings (Settings → Branches → branch protection). GitHub Actions can't self-configure branch protection.

Out of scope

• CI for the consumer sites (their own repos).
• The deploy workflows (untouched).

[mhenrixon]

CI is green on 3.2 / 3.3 / 3.4 ✅

Two additional CI-blocking bugs surfaced only once the workflow ran against the published daisyui 1.2.0 (the local suite passed by relying on the sibling ../daisyui checkout). Both are fixed in follow-up commits:

1. fix(spec): require daisy_ui — the component suite include DaisyUI but nothing loaded the daisyUI kit (docs-kit expects the host app's require: "daisy_ui"). On CI: NameError: uninitialized constant DocsUI::Shell::DaisyUI. Fixed by requiring daisy_ui in spec_helper.rb, exactly as a consuming site does.

2. ci: scope the rubocop rake task — RuboCop loaded docs/.rubocop.yml (the dogfood site's config, which inherit_gems rubocop-rails-omakase → panolint, absent from the gem's bundle) and crashed during config resolution. An AllCops Exclude stops linting those files but not loading their config as directory inheritance, so the rake task now passes explicit paths (app lib spec + root files). Verified with --debug that only the root .rubocop.yml is read.

Both were reproduced locally by hiding the sibling checkout so Bundler resolves daisyui 1.2.0 from rubygems (CI's exact state) — rake is green there too.