feat: Expose secret_scanning_push_protection_custom_link on github_organization_settings

[JamBalaya56562]

Summary

Adds two new fields to github_organization_settings (resource) and
github_organization (data source):

• secret_scanning_push_protection_custom_link_enabled (bool,
  Optional + Computed) — toggles whether a custom URL is shown to
  contributors who try to push a secret.
• secret_scanning_push_protection_custom_link (string,
  Optional + Computed) — the URL itself.

The diff follows the existing members_can_fork_private_repositories
pattern (schema, buildOrganizationSettings, debug log, read) plus
test cases, docs, templates, and example HCL.

Upstream wiring

Both fields map to new properties on the Organization struct in
go-github v86, added in
google/go-github#4188:

• Organization.SecretScanningPushProtectionCustomLinkEnabled
• Organization.SecretScanningPushProtectionCustomLink

This repo picked up v86 in #3413, so no dependency change is needed.

API status — please read

These two fields are not currently listed in the public REST docs
for Update an organization,
but they are returned by GET /orgs/{org} and accepted by
PATCH /orgs/{org} in production. The upstream go-github PR
explicitly notes "observed but undocumented" and was reviewed/merged
under that understanding.

Verified end-to-end against a real org (aletheia-works) while
testing the go-github PR — both GET and PATCH responses include both
fields.

I am opening this here so terraform users can manage the setting
they already see in the GitHub UI. Happy to hold the PR until the
REST docs catch up if maintainers prefer.

Relationship to enterprise resource

There is already a secret_scanning_push_protection_custom_link
(string only, no _enabled toggle) on
github_enterprise_security_analysis_settings. The two settings
control different scopes:

• The enterprise value sets the default link inherited by orgs in
  the enterprise.
• The organization value (this PR) overrides that default for one
  org and adds an explicit _enabled toggle that the API surfaces
  separately.

If both resources manage the same org, the org-level value wins. This
is documented in the new secret_scanning_push_protection_custom_link_enabled
description.

Schema choice

Both fields are Optional + Computed with no Default, matching the
conservative pattern used in #3389 and #3432: if the user does not
configure the field, the provider reads the org's current value and
does not silently write anything. Happy to switch to Default: false
for the bool if reviewers prefer.

Intentionally not in this PR

• Cross-field validation (e.g. CustomizeDiff to reject
  _enabled = true with empty URL, or vice versa). The existing
  enterprise-level resource has no such validation; matching it for
  now. Can be added in a follow-up once API rejection behavior is
  characterized.
• URL format validation (ValidateFunc). Same rationale.

Test plan

• go build ./...
• go vet ./...
• go test -run TestNeverMatch ./github/... (compile-level check
  for the new test assertions; acceptance tests need TF_ACC=1
  + tokens and were not run locally)
• CI acceptance tests

Related

• feat: Expose deploy_keys_enabled_for_repositories on github_organization_settings #3432 (deploy_keys_enabled_for_repositories) — sibling field from
  the same upstream go-github PR. Independent scope, opened separately
  so it can land without being held up by the undocumented-API
  discussion here.
• feat: Expose remaining org attributes in github_organization_settings #3389 — another open PR adding org-level fields
  (default_repository_branch, secret_scanning_validity_checks_enabled).
  Independent scope, not touched.

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