cleanup: remove or wire currently unused provider and registry helpers

Context

A quick audit of main found several methods and fields that appear to be unused or only partially integrated. They are not the highest-priority runtime bugs, but they make the core extension harder to reason about and suggest unfinished design paths.

Likely orphaned or underused code

Unused helpers

• ProviderFactory.getRequiredConfigKeys(...)
• BaseHttpProvider.loadConfig(...)
• OllamaProvider.listInstalledModels(...)

State written but never read

• ModelRegistry.modelDirLoaded
• ModelRegistry.overrideLoadMessage

Abstract methods that are effectively bypassed

GeminiProvider must implement buildApiUrl(...) and buildHeaders(...) only because of the BaseHttpProvider shape, but both methods throw UnsupportedOperationException because Gemini overrides sendChatRequest(...) instead.

Why this matters

None of these are catastrophic on their own, but together they create ambiguity about the intended architecture:

• it is harder to tell which config/validation paths are actually authoritative
• dead helpers invite future bugs when someone updates one path but not the real one
• the base-provider contract is not fully aligned with the Gemini implementation

Suggested cleanup directions

1. Remove helpers that are no longer part of the real design.
2. Or wire them into the active code paths if they are meant to stay.
3. Revisit the BaseHttpProvider abstraction so providers like Gemini do not need placeholder methods that are never valid to call.
4. Add a small architecture note or test coverage for any helpers that are intentionally reserved for future use.

Affected files

• src/main/providers/ProviderFactory.scala
• src/main/providers/BaseHttpProvider.scala
• src/main/providers/OllamaProvider.scala
• src/main/providers/GeminiProvider.scala
• src/main/providers/ModelRegistry.scala

Start by reading the affected provider and registry files: ProviderFactory.scala, BaseHttpProvider.scala, OllamaProvider.scala, GeminiProvider.scala, and ModelRegistry.scala. Trace each listed helper and field to confirm whether it is unused or partially integrated, then review existing tests before choosing whether to remove or wire it. Done means the cleanup direction is resolved, the provider abstraction is consistent, and any intentional behavior has coverage or an architecture note.