fix(organization): apply visibility via AdminEditUser fallback

[saada]

Summary

Fixes #141. Changing visibility on a forgejo_organization (e.g. private → public) fails with:

Error: Provider produced inconsistent result after apply

The Forgejo PATCH /orgs/{org} endpoint can silently ignore visibility changes on some Forgejo versions — EditOrg returns success but the org's visibility on the server is unchanged. The post-apply read-back then disagrees with the plan and Terraform aborts.

Orgs share the underlying user schema in Forgejo, and PATCH /admin/users/{user} reliably persists visibility writes. The forgejo_user resource already routes visibility through that endpoint. This PR mirrors that pattern in Update():

1. Call EditOrg as before (so non-admin users keep working for the non-visibility fields).
2. Read the org back.
3. If the read-back visibility disagrees with the planned value, retry the visibility update via AdminEditUser, then re-read.

Non-admin users whose Forgejo instance applies EditOrg visibility correctly are unaffected — the fallback only fires on the broken path. If the fallback is needed but the token lacks the write:admin scope, the diagnostic points the user at the missing scope rather than the generic 403.

Test plan

• go build ./... passes
• go vet ./... passes
• gofmt -l clean
• Added a private → public step to TestAccOrganizationResource (the exact transition reported in forgejo_organization: "Provider produced inconsistent result after apply" when changing visibility #141). Acceptance tests need a Forgejo instance — CI will run them via the existing matrix.
• Followed by a public → private step so the trailing UseStateForUnknown check in the test still proves its original behavior.

[acch]

Hi @saada, thank you very much for creating this workaround! I do have a few concerns, however:
As mentioned in #125, I'm unable to find any documentation in Forgejo on the observed behavior. Hence, I'm considering this to be a bug in the Forgejo API server, rather than designed behavior.

Your workaround changes the semantics of the forgejo_organization resource to now require admin privileges - which wasn't necessary before - but only if the bug is encountered. Without a better understanding, I'm not sure how we could even document this: "Admin privileges may be required in some cases, but not in others...". This is far from optimal.

I would be willing to accept this as a temporary workaround. For the temporary nature of this we would need an issue with Forgejo for being able to track progress towards resolution. Please open an issue there, or identify an existing one, describing the exact problem. I guess this would require reproducing the issue with plain API requests, to rule out any misbehavior of the provider and/or the Forgejo SDK it uses. This is to ensure that the workaround is really temporary, while Forgejo works on implementing a proper fix...

[acch]

Hi @saada - any update on the issue with upstream Forgejo? Do you have questions, or is there anything I can help with?