fix(loader): require "guardrails/configuration" from the top-level entry

Local-build verification (gem build → install in sandbox → require
"guardrails") surfaced that `Guardrails.configure` was undefined
unless a caller also `require`d `guardrails/configuration` themselves.

That's exactly what an embedded user's
`config/initializers/guardrails.rb` would NOT do — Rails autoloads
the initializer after `require "guardrails"` and no other code path
pulls in Configuration unless the rake task does (which doesn't run
at boot). So `Guardrails.configure { |c| c.visual_diff.enabled = true }`
in an initializer NoMethodErrors on first app boot.

Fix: require "guardrails/configuration" from `lib/guardrails.rb`.
Two-line addition, no behavior change for anyone who was already
requiring detector files directly.

Regression spec in `spec/guardrails_spec.rb` locks the contract:
asserts both Guardrails.configure and .configuration are callable
after `require "guardrails"` alone, and the block actually sets
the values.

Worth noting this slipped past 459 specs because every previous
visual_diff/configuration spec explicitly `require`d both files.
The actual user code path (initializer-only require) wasn't
covered until now.

Full suite 461/461 (up from 459).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: jathayde

lib/guardrails.rb

@@ -1,6 +1,12 @@
 # frozen_string_literal: true
 
 require_relative "guardrails/version"
+# Configuration carries the `Guardrails.configure { |c| ... }` block
+# users place in `config/initializers/guardrails.rb`. Loaded eagerly
+# at `require "guardrails"` time so the initializer doesn't NoMethodError
+# on first use — caught by the local-build verification of 1.0.0
+# before the third publish attempt.
+require_relative "guardrails/configuration"
 require_relative "guardrails/railtie" if defined?(Rails::Railtie)
 
 module Guardrails

spec/guardrails_spec.rb

@@ -4,4 +4,27 @@
   it "has a version number" do
     expect(Guardrails::VERSION).not_to be_nil
   end
+
+  # The `Guardrails.configure { |c| c.visual_diff.enabled = true }` block
+  # lives in `config/initializers/guardrails.rb` for embedded installs.
+  # That initializer is invoked after `require "guardrails"` and nothing
+  # else — if configuration.rb isn't auto-loaded by the top-level entry,
+  # the initializer NoMethodErrors on first boot. Caught by 1.0.0's
+  # local-build verification; locking in here so a future refactor of
+  # `lib/guardrails.rb` doesn't silently regress.
+  describe "require \"guardrails\"" do
+    it "exposes Guardrails.configure (Configuration auto-loaded)" do
+      expect(described_class).to respond_to(:configure)
+      expect(described_class).to respond_to(:configuration)
+    end
+
+    it "yields a usable Configuration in the block" do
+      expect {
+        described_class.configure { |c| c.visual_diff.enabled = true }
+      }.not_to raise_error
+      expect(described_class.configuration.visual_diff.enabled).to be true
+    ensure
+      described_class.reset_configuration!
+    end
+  end
 end