Cross-repository label-ID enumeration oracle via unscoped DeleteIssueLabel API

Affected: Go: code.gitea.io/gitea

## Summary

The API endpoint `DELETE /repos/{owner}/{repo}/issues/{index}/labels/{id}` loads the label by ID with a **global, unscoped** lookup and never verifies the label belongs to the URL's repository (or its owning organization). Because the response status differs by whether the label ID exists **anywhere on the instance** (204) versus not (422), an authenticated user can use the endpoint as a **cross-repository label-ID existence / enumeration oracle**, including for labels in repositories and organizations they cannot access.

## Severity

- The leaked information is minimal (existence/count of label IDs instance-wide); **no label name, color, or owning repository is disclosed, and no cross-repository write occurs.**

## Affected / patched versions

- **Affected:** through **1.26.3** (latest at time of report). - **Patched:** none yet.

## Details

`DeleteIssueLabel` resolves the label with a global loader and never checks its scope:

```go // routers/api/v1/repo/issue_label.go (DeleteIssueLabel) label, err := issues_model.GetLabelByID(ctx, ctx.PathParamInt64("id")) // global, unscoped ```

`GetLabelByID` (`models/issues/label.go`) is `e.ID(labelID).Get(l)` with **no** `repo_id` / `org_id` filter. The handler never verifies `label.RepoID == ctx.Repo.Repository.ID` (nor the org-label equivalent), and the downstream `issue_service.RemoveLabel` (`services/issue/label.go`) only re-checks the doer's write permission on the **issue's own** repository — never that the…