Describe the bug
When Cloudlist encounters transient API failures while enumerating Cloudflare or GCP resources, the provider implementations swallow the error and return an empty Resources list. Downstream consumers client interpret this as "cloud integration has no assets" even though the failure was caused by the provider.

Specific examples:
Cloudflare provider (pkg/providers/cloudflare/cloudflare.go:104-109) ignores the error returned from dnsProvider.GetResource:

if p.services.Has("dns") {
    dnsProvider := &dnsProvider{id: p.id, client: p.client, extendedMetadata: p.extendedMetadata}
    if resources, err := dnsProvider.GetResource(ctx); err == nil {
        finalResources.Merge(resources)
    }
}
return finalResources, nil  // ← Error dropped, returns empty

If ListDNSRecords fails (rate limits, network issues), the error is dropped and the inventory stays empty.

Issue scope:
This error swallowing pattern exists across all providers.

Problem:
Transient API failures (rate limiting, network issues, temporary outages) become indistinguishable from "no assets configured."

Impact:

• Higher layers don't retry operations since errors are suppressed
• No meaningful error messages are surfaced to clients
• Intermittent failures occur where scans sometimes return assets and sometimes return nothing, without any configuration changes
• Clients have no visibility into the underlying API issues

Cloudlist version:
v1.1.1-0.20251016105953-a39e7ee23dbd

Additional context:
This was observed while using Cloudlist as an SDK and investigating intermittent scan failures. No screenshots available as this is a behavioral/logic issue.