fix: support in-place updates for repository custom property values

[milan-dewilde]

Resolves #3377

---

Before the change?

• Changing property_value on github_repository_custom_property produces a -/+ destroy and then create replacement plan, because property_value is declared ForceNew: true and the resource has no Update function (only Create, Read, Delete).
• On apply, the destroy step calls client.Repositories.CreateOrUpdateCustomProperties with Value: nil, which per the GitHub REST docs "removes or 'unsets' the property value". The subsequent create step re-sets it, leaving a window where the property is unset (or reverts to the org-level default) which is breaking downstream systems that depend on the property being continuously set.
• The underlying API (PATCH /repos/{owner}/{repo}/properties/values) is documented as upsert, and Create already calls it. The sibling resource github_organization_custom_property is wired with Create + Read + Update + Delete for the analogous org-level API; the repo-level resource is the outlier.

After the change?

• Wire an Update function that delegates to Create, mirroring the pattern used by github_organization_custom_properties.
• Remove ForceNew: true from the property_value schema entry. Identity fields (repository, property_name, property_type) remain ForceNew — those are immutable on the GitHub API side.
• Add an acceptance subtest (updates custom property value in place without replacement) that applies an initial value, updates it, asserts the resource ID is unchanged across the two steps (proving no replacement), and asserts an empty follow-up plan.
• A value change now plans as ~ update in-place and issues a single upsert, with no intermediate unset window.

Pull request checklist

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

No schema migration is required: removing ForceNew from a field does not change how the value is stored in state, so existing state files remain compatible. The website docs already describe property_value as a mutable input and never claimed forced replacement, so no doc update is needed.

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

• Yes
• No

Removing ForceNew is a non-breaking schema relaxation: configurations that previously planned as replacements will now plan as in-place updates. Configurations with unchanged property_value continue to plan as no-ops. No state migration is required.

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