Remove CLOUD_PROVIDER switch — contradicts multi-cloud model

[AhmadHammad21]

Problem

CLOUD_PROVIDER (in apps/core/src/opendevops_core/config.py:34) selects ONE active provider whose SDK tools get loaded into ALL_TOOLS (apps/core/src/opendevops_core/agent/core.py:32). Only AWS has SDK tools today; Azure's provider stub returns [] and logs Azure provider not yet implemented — no cloud tools loaded.

Effect on OSS:

Setting	What loads
CLOUD_PROVIDER=aws (default)	21 AWS boto3 tools + bash/skills/history. Azure works via bash az.
CLOUD_PROVIDER=azure	Zero Azure SDK tools (the stub returns []) and you lose the 21 AWS tools. Net-negative.

The switch contradicts the multi-cloud model we shipped (per-provider credential resolution in the bash tool + Azure via az/kubectl + skills). Users running OSS hit a confusing warning and lose tools when they try to "enable Azure."

Recommendation

Remove the switch and the provider registry; always load AWS tools + bash + skills. Azure is automatically available via az/kubectl + skills (bash tool already handles credential resolution per binary).

Affected files

• apps/core/src/opendevops_core/config.py (drop cloud_provider field)
• apps/core/src/opendevops_core/providers/__init__.py and providers/base.py (drop registry/protocol)
• apps/core/src/opendevops_core/providers/azure/__init__.py, providers/aws/__init__.py, providers/gcp/__init__.py (drop the Provider classes; keep the credentials/context modules)
• apps/core/src/opendevops_core/agent/core.py:32 — replace get_active_provider().tools() + SHARED_TOOLS with the AWS tools list directly
• apps/core/src/opendevops_core/agent/prompts.py:102 — drop default_cloud switching; the prompt already explains both clouds
• apps/backend/src/api/app.py and providers/aws/{event_consumer,poller}.py — replace get_active_provider().polling_loop() / event_consumer_loop() with direct imports from providers/aws/*
• .env.example — remove CLOUD_PROVIDER

Alternative (smaller diff)

Keep CLOUD_PROVIDER as just a prompt-hint string; always load AWS tools regardless. Leaves the abstraction in place for future structured Azure SDK tools, at the cost of keeping a half-implemented stub.

Deferred. Reference: discussion in chat 2026-05-29.