Design API key infrastructure for authenticated providers

[steveclarke]

Overview

Several Bible APIs require an API key. Before adding these providers, we need a consistent design for how the gem handles authentication.

APIs waiting on this

• API.Bible (scripture.api.bible) — 2,500+ versions, 1,600+ languages
• HolyBible.dev — KJV, free tier

Questions to answer

• How does a user supply an API key? Constructor argument? Global config? Environment variable?
• Should there be a Votd.configure block (similar to other gems)?
• Should authenticated and unauthenticated providers share the same base class or split?
• How do we handle missing/invalid keys gracefully — raise immediately or fall back to default verse?

Proposed direction

# Option A: constructor argument
votd = Votd::APIBible.new(api_key: "abc123", version: :esv)

# Option B: global config
Votd.configure do |config|
  config.api_bible_key = "abc123"
end
votd = Votd::APIBible.new(:esv)

Option A is simpler and more explicit. Option B is friendlier for apps that configure once at startup.

Acceptance criteria

• Agreed-upon API key design documented
• Votd::Base or a new Votd::AuthenticatedBase supports the pattern
• Ready for API.Bible and HolyBible.dev providers to be built on top of it