cleanup: remove or wire currently unused provider and registry helpers

[JNK234]

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

[JNK234]

Rechecked against ff094c6 on main. Still relevant as cleanup, but not a current release blocker. The clearest remaining examples are BaseHttpProvider.loadConfig(...) and the write-only ModelRegistry.modelDirLoaded / overrideLoadMessage fields. The issue should probably stay open as an architecture cleanup task rather than being treated like a runtime regression.

[JNK234]

Rechecked after pulling 3d1283f on main. Still relevant as cleanup. The recent changes did not remove BaseHttpProvider.loadConfig(...) or the write-only ModelRegistry.modelDirLoaded / overrideLoadMessage state, so the architecture-cleanup part of this issue remains.