fix: avoid 422 when enterprise policy controls org fork setting

[andrewesweet]

Resolves #2689
Relates to #1333

---

Before the change?

• members_can_fork_private_repositories has Default: false in the schema, causing the field to always be sent to the GitHub API even when not explicitly set by the user.
• When an enterprise-level policy locks this setting, the API returns a 422 validation error.

After the change?

• Removed Default: false from the schema so the field is only included in API calls when explicitly configured by the user.
• This matches the pattern used by members_can_create_internal_repositories (enterprise-only field with no default).
• Updated description and docs to note the enterprise policy interaction.

Users who never set this field see no behavioral change — the API default is false and the Read function still populates state from the API response.

Pull request checklist

• Schema migrations have been created if needed
• 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?

• 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! 🚀

[deiga]

I think this won't be as simple as this. Since we use d.GetOk to identify if members_can_fork_private_repositories should be sent to the API it would still continue sending the value.

It would be important to add a test that verify's that members_can_fork_private_repositories isn't actually being set or updated in the Read function

[andrewesweet]

Thanks for the review, @deiga. I've updated the PR.

The schema now has Computed: true on the field, and the build function uses d.GetOkExists instead of shouldInclude. I followed the same pattern as allow_forking in resource_github_repository.go.

I also added:

• Unit tests for buildOrganizationSettings covering nil when omitted, non-nil when explicitly set to true or false, and nil on updates when unchanged.
• An acceptance test (TestAccGithubOrganizationSettings_omittedForkFieldProducesCleanPlan) verifying no phantom diff after apply.

[andrewesweet]

I also spotted the same problem with members_can_create_internal_repositories and created #3385 and #3386 to fix it separately.