Regression in v6.13.0: github_issue_label create no longer adopts pre-existing labels (422 already_exists)

### Summary

In **v6.13.0**, `github_issue_label` fails to create a label whose name already exists on the repository, returning:

```
POST https://api./repos///labels: 422 Validation Failed [{Resource:Label Field:name Code:already_exists Message:}]
```

This worked in **v6.12.1** and earlier: the resource adopted the existing label (updated it) instead of blindly creating it.

### Root cause

#3342 ("refactor: migrate resource_github_issue_label to context-aware CRUD") split the old idempotent `resourceGithubIssueLabelCreateOrUpdate` into separate `Create`/`Update` functions. The PR was described as "no behavior change", but it dropped the GET-first existence check from the create path.

- **v6.12.1** `resourceGithubIssueLabelCreateOrUpdate`: calls `client.Issues.GetLabel(...)` first; if the label exists it `EditLabel`s, otherwise `CreateLabel`. Idempotent — adopts pre-existing labels.
- **v6.13.0** `resourceGithubIssueLabelCreate`: calls `client.Issues.CreateLabel(...)` directly with no prior `GetLabel`, so it 422s whenever the label already exists.

The doc for this resource still explicitly promises the old behavior:

> Issue labels are keyed off of their "name", so pre-existing issue labels result in a 422 HTTP error if they exist outside of Terraform. Normally this would not be an issue, except new repositories are created with a "default" set of labels ... This resource will first check if the label exists, and then issue an update, otherwise it will create.

That documented "check first, then update, otherwise create" behavior no longer matches the v6.13.0 create path.

### Impact

Very common in practice: GitHub/GHE seed every new repository with a default label set (`bug`, `documentation`, `duplicate`, `enhancement`, `good first issue`, `help wanted`, `invalid`, `question`, `wontfix`). Any config that manages those same names with `github_issue_label` now fails on the first apply for a freshly created repo (or any repo where the label was created outside Terraform), where it previously adopted them.

### Reproduce

1. On a repo that already has a `bug` label (e.g. a newly created repo with GitHub's defaults), declare:
```hcl
resource "github_issue_label" "bug" {
repository = "some-repo"
name = "bug"
color = "d73a4a"
}
```
2. `terraform apply` with provider **v6.13.0** → `422 already_exists`.
3. Same config with **v6.12.1** → succeeds (adopts/updates the existing label).

### Expected

`github_issue_label` create should restore the GET-first behavior (adopt the existing label via update) as documented, rather than a blind `CreateLabel`.

### Workaround

Pin `integrations/github` to `>= 6.0, < 6.13.0`.

### Versions

- Provider: v6.13.0 (regressed) vs v6.12.1 (works)
- Affects both github.com and GitHub Enterprise Server.

Start at resource_github_issue_label and compare resourceGithubIssueLabelCreate with the former resourceGithubIssueLabelCreateOrUpdate path. Verify the GET-first lookup and the documented adopt-or-create behavior, then run the relevant github_issue_label tests or reproduce against a repository containing a default label; done means an existing label is updated without a 422 and a missing label is created.

Written by the indexing model from the issue text.