[BUG]: have an option to set org level forking policy

[lee2sh]

Resolves #ISSUE_NUMBER

---

Before the change?

When managing a repository in an organization that has disabled forking, setting allow_forking on the github_repository resource would cause API errors (HTTP 422) because the GitHub API rejects the allow_forking parameter when the organization doesn't permit forking.

After the change?

Added a new org_allow_forking attribute (defaults to true) that controls whether the allow_forking setting is sent to the Github API. When org_allow_forking = false, the provider skips sending allow_forking to the API, preventing errors for organizations that have disabled forking

Pull request checklist

• Schema migrations have been created if needed (example)
• [X ] Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

• Yes
• No

---

[github-actions]

👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labeled with Status: Up for grabs. You & others like you are the reason all of this works! So thank you & happy coding! 🚀

[stevehipwell]

I don't think the PR is necessary, nor do I think the UX works.

FYI #3094 fixes this issue as it's just an implementation bug.

[lee2sh]

I don't think the PR is necessary, nor do I think the UX works.

FYI #3094 fixes this issue as it's just an implementation bug.

The PR has an edge case. If a user explicitly sets allow_forking (true or false) on an organization that has disabled private repo forking, they'll likely still get a 422 error. The GetOk() fix only handles the case where allow_forking is unset. I believe with this approach, it would proactively respect org settings by omitting the field from the request entirely.

[stevehipwell]

@lee2sh the GitHub API and therefore this provider are full of edge cases. This PR just moves the edges around without fixing the source of the issue. An actual improvement would be to lookup the org settings as a data source but the API doesn't exist.

[lee2sh]

gotcha makes sense. will close the PR.