Expose Servus::Result as a top-level primary concern

[fractaledmind]

Summary

• Expose Servus::Result at the top level with class-method factories .success(data = nil) and .failure(message = nil, data:, type:), so the result object can be used from any code — controllers, jobs, plain POROs — not just inside a Servus::Base subclass.
• Servus::Base#success and #failure now delegate to Servus::Result.success / .failure (single source of truth).
• Servus::Support::Response is kept as a silent alias of Servus::Result for backwards compatibility — all existing references continue to resolve unchanged.

# Outside a service
def import_rows(rows)
  return Servus::Result.failure("no rows") if rows.empty?

  Servus::Result.success(imported: rows.count)
end

# Inside a service (unchanged — sugar over the same factories)
class MyService < Servus::Base
  def call
    return failure("Invalid amount") if @amount <= 0

    success(transaction_id: charge.id)
  end
end

Docs

• site/core/responses.md rewritten to lead with Servus::Result as the primary concept, with a dedicated "Outside a service" section before the existing "Inside a service" content. URL unchanged.
• Sidebar label updated from "Responses" to "Results".
• CHANGELOG.md has an [Unreleased] entry — no version bump in this PR (suggest 0.6.0 since it's a new public API surface, though fully backwards-compatible).

Test plan

• bundle exec rspec — 783 examples, 0 failures (was 770; +13 new in spec/servus/result_spec.rb)
• bundle exec rubocop — 82 files, no offenses
• CI passes on Ruby 3.2 / 3.3 / 3.4

🤖 Generated with Claude Code