Remove hackney from user-facing HTTP call paths (OAuth + OIDC discovery)

User story

As an operator running Lightning, I want all user-triggered outbound HTTP
requests to flow through Finch (not hackney) so that vulnerabilities in
hackney's request handling cannot be reached via the OAuth credential flow or
OIDC discovery — narrowing our exposure to the hackney 4.x CVE class
(CVE-2026-47066 through CVE-2026-47077: DoS, header injection, SSRF bypass,
redirect handling) regardless of which hackney version we ship.

Details

Two user-triggered paths currently route HTTP through hackney:

1. OAuth2 token exchange / refresh — config :oauth2, adapter: Tesla.Adapter.Hackney in config/config.exs:81. Used by all OAuth
   credentials (Google, Salesforce, generic OIDC providers).

2. OIDC discovery document fetch — lib/lightning/auth_providers/ well_known.ex uses HTTPoison.Base, which depends directly on hackney.

Other hackney usages out of scope here:

• tzdata (transitive) — periodic IANA timezone DB downloads to a
  hardcoded URL. Not reachable via attacker-controlled input. Stays.
• lib/mix/tasks/install_schemas.ex — build/deploy-time only, not a
  production request path. Stays for now.

Once this migration lands, no user-initiated request hits hackney; the
remaining hackney call (tzdata) operates against a hardcoded
data.iana.org URL and so is not exploitable via the CVE class above.

We already have Lightning.Finch running as the application's HTTP pool
(lib/lightning/application.ex:142), used by Tesla globally
(config.exs:182) and by Lightning.ApolloClient.

Implementation notes

1. Swap the oauth2 Tesla adapter (config/config.exs:81):

- config :oauth2, adapter: Tesla.Adapter.Hackney
+ config :oauth2, adapter: {Tesla.Adapter.Finch, name: Lightning.Finch}

No code changes in lib/lightning/auth_providers/common.ex or
salesforce.ex — those call OAuth2.Client directly and the adapter
swap is transparent.

2. Rewrite WellKnown to use Tesla (lib/lightning/auth_providers/ well_known.ex):

Replace use HTTPoison.Base with a Tesla client. Adapter is inherited
from the global :tesla config (already Finch).

3. Update error pattern in auth_config_form.ex:74 to match Tesla's
{:error, reason} shape rather than %HTTPoison.Error{reason: ...}.

4. Consider dropping :httpoison from mix.exs: after the rewrite,
only install_schemas.ex (mix task) uses it. We can either keep it for
the mix task or move that to Req/Tesla as a small follow-up.

Test coverage to exercise:

• OAuth credential creation flow for each provider (Google, Salesforce,
  generic OIDC) in the credential live views.
• OIDC discovery against a real provider in dev (the WellKnown tests use
  mocks, so manual smoke test recommended).
• Existing test suite: mix test test/lightning/auth_providers/ and
  mix test test/lightning_web/live/credential_live_test.exs.

Release notes

Internal hardening: OAuth token exchange and OIDC discovery now use
Finch instead of hackney, removing hackney from all user-triggered HTTP
call paths.

User acceptance criteria

• OAuth credential creation works for Google, Salesforce, and a
  generic OIDC provider.
• OIDC discovery (/.well-known/openid-configuration fetch) still
  populates the WellKnown struct correctly.
• grep -rn "HTTPoison\.\|use HTTPoison" lib/lightning lib/lightning_web
  returns no hits (excluding lib/mix/tasks/).
• grep -n "Tesla.Adapter.Hackney" config/ returns no hits.
• All existing tests pass; mix verify clean.
• Manual smoke test: create + refresh an OAuth credential in dev.

Start with config/config.exs, lib/lightning/auth_providers/well_known.ex, and auth_config_form.ex:74; inspect the existing Lightning.Finch setup in lib/lightning/application.ex and the Tesla configuration. Run the auth provider and credential live-view tests, then verify the OAuth providers, OIDC discovery, grep acceptance checks, and mix verify all pass.