fix(github_repository_file): produce signed delete commits via GraphQL

[LudovicTOURMAN]

Resolves #3364

Before the change?

github_repository_file delete commits go through DELETE /repos/{owner}/{repo}/contents/{path}. Unlike PUT on the same endpoint, that path does not trigger GitHub's server-side web-flow commit signing: the commit's committer stays as the caller identity (App bot or user) instead of being rewritten to GitHub <noreply@github.com>, and no PGP signature is attached (commit.verification = { verified: false, reason: \"unsigned\" }).

For organisations that enforce a require signed commits ruleset on protected branches, this means:

• terraform apply creating or updating a file → signed, accepted.
• terraform destroy (or any change to file / branch triggering a replace) → unsigned, silently rejected or landing as an unsigned commit.

PR #2736 aligned the payload shape between create/update/delete but could not close this gap because the missing signature is a property of the REST DELETE endpoint itself, not the JSON body.

After the change?

resourceGithubRepositoryFileDelete now uses the GraphQL createCommitOnBranch mutation with a single fileChanges.deletions entry. That mutation always produces a web-flow signed commit, for both additions and deletions, so delete commits now satisfy the same ruleset that create/update commits already satisfy (when commit_author/commit_email are left unset).

Summary of the code change:

• Added a small getBranchHeadOid helper that resolves the current tip of the target branch via GraphQL, used as expectedHeadOid for the mutation.
• Replaced the REST DeleteFile call with the mutation; archived-repo error handling is preserved via handleArchivedRepoDelete.
• Added a note in website/docs/r/repository_file.html.markdown explaining the signing guarantees on delete vs. create/update.

Create and update paths are intentionally left on the REST Contents API: createCommitOnBranch does not accept a custom author/committer, so routing create/update through it would make the existing commit_author / commit_email arguments effectively no-ops, which is a user-visible breaking change. Keeping them on REST preserves today's behaviour for users who do set those fields, and delete was the only path that could not already produce a signed commit under any configuration.

Pull request checklist

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

The existing TestAccGithubRepositoryFile cases exercise the full resource lifecycle, including destroy, so the new delete path is covered by the current acceptance matrix against a real GitHub repository. No unit-test harness is available for the GraphQL client in this package.

Does this introduce a breaking change?

• Yes
• No

The delete path previously emitted an unsigned commit attributed to the caller; it now emits a web-flow signed commit. The only user-visible difference is the committer identity switching from the caller to GitHub <noreply@github.com> on delete commits, matching what create/update already do when commit_author/commit_email are unset.

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