`cloudsmith_oidc` refresh requires elevated org permissions, blocking least-privileged Terraform plan/apply separation

Hi Cloudsmith team,

We are trying to manage Cloudsmith configuration with Terraform while keeping a strict separation between our Terraform plan and apply identities.

Our intended model is:

- PR plans run with a least-privileged Cloudsmith service account.
- Applies run with a more privileged Cloudsmith service account.
- The plan identity should be able to produce a trustworthy plan for review without having broad organization-level permissions.

This becomes difficult once `cloudsmith_oidc` resources are present in the Terraform state.

Even when a PR does not modify OIDC configuration, Terraform refreshes existing `cloudsmith_oidc` resources during `terraform plan`. With a lower-privileged plan identity, refresh fails with a 403:

```hcl
Error: 403 Forbidden

with cloudsmith_oidc.provider["example-provider"],
on oidc_providers.tf line 21
```

The practical impact is that any stack containing `cloudsmith_oidc` resources requires the plan identity to have highly elevated organization-level permissions just to refresh existing OIDC configuration.

That means we have to choose between:

- giving the PR plan identity broad Cloudsmith permissions, even for unrelated changes; or
- accepting failed / incomplete Terraform plans whenever OIDC resources are present in state.

This is painful because OIDC providers are exactly the kind of security-sensitive resources we want to manage declaratively, but the refresh permission requirement makes least-privileged Terraform planning hard to preserve.

Could you confirm whether this permission behavior is expected for reading existing OIDC provider configuration through the Terraform provider/API?

Thanks!

Start with the cloudsmith_oidc instance at oidc_providers.tf line 21 and reproduce the 403 during terraform plan using separate plan and apply identities. Trace the refresh/read path for existing OIDC providers and verify which Cloudsmith permissions it requires. Done means confirming whether the requirement is expected and identifying the provider or API behavior that must change or be documented.

Written by the indexing model from the issue text.