PATCH /api/v1/repos/{owner}/{name}/labels/{id} renames or recolours a label, as MCP repo_labels update and the labels page already do #7878

PATCH /api/v1/repos/:owner/:name/labels/:id now renames or recolours a label over plain HTTP, so an agent can fix a typo without deleting the label. The label keeps its id, so every issue and pull that carries it still does. The new test file, the contract tests, bun test test/mcp-size.test.ts, bun x tsc --noEmit and bun scripts/gate.ts all pass. I did not run the full suite, which the forge's check runs on the push.

• Behaviour: the body is { name?, color? }, and an omitted field keeps its current value, as on the MCP tool. It answers 200 with { id, name, color }. It calls the existing updateLabel, so the rename or recolour is recorded on the trail as the labels page's is.
• Scope: it needs an admin token scope, as POST and DELETE do. An unknown id is 404. Neither field given, a non-string field, a name another label already has, or a colour that is not six hex digits is 422.
• 422 body: { error: "invalid" | "taken", message }, where message is LABEL_WORDS.shape or LABEL_WORDS.taken, the same words the labels page and MCP use. The "neither field" case uses the MCP tool's words: "update names a new name, a new color, or both".
• Contract: the new route file patchApiV1ReposOwnerNameLabelsId.ts is added and src/contract/openapi/routes/index.ts regenerated with scripts/openapi-routes.ts.
• Test: test/api-labels-update.test.ts covers rename, recolour, an issue still carrying the renamed label, admin-only, 404 and 422. I did not check that each case fails without the route.
• MCP doc: the repo_labels doc string now says PATCH/DELETE …/labels/:id. Nothing else in the MCP changed, and docs/MCP.md and README.md are untouched.

I did not add a way to move a label between repositories or to reorder labels, which the issue didn't ask for.

Closes #7865

PATCH /api/v1/repos/:owner/:name/labels/:id now renames or recolours a label over plain HTTP, so an agent can fix a typo without deleting the label. The label keeps its id, so every issue and pull that carries it still does. The new test file, the contract tests, bun test test/mcp-size.test.ts, bun x tsc --noEmit and bun scripts/gate.ts all pass. I did not run the full suite, which the forge's check runs on the push.

• Behaviour: the body is { name?, color? }, and an omitted field keeps its current value, as on the MCP tool. It answers 200 with { id, name, color }. It calls the existing updateLabel, so the rename or recolour is recorded on the trail as the labels page's is.
• Scope: it needs an admin token scope, as POST and DELETE do. An unknown id is 404. Neither field given, a non-string field, a name another label already has, or a colour that is not six hex digits is 422.
• 422 body: { error: "invalid" | "taken", message }, where message is LABEL_WORDS.shape or LABEL_WORDS.taken, the same words the labels page and MCP use. The "neither field" case uses the MCP tool's words: "update names a new name, a new color, or both".
• Contract: the new route file patchApiV1ReposOwnerNameLabelsId.ts is added and src/contract/openapi/routes/index.ts regenerated with scripts/openapi-routes.ts.
• Test: test/api-labels-update.test.ts covers rename, recolour, an issue still carrying the renamed label, admin-only, 404 and 422. I did not check that each case fails without the route.
• MCP doc: the repo_labels doc string now says PATCH/DELETE …/labels/:id. Nothing else in the MCP changed, and docs/MCP.md and README.md are untouched.

I did not add a way to move a label between repositories or to reorder labels, which the issue didn't ask for.

I fixed one of the two failures and left the other alone.

• docs/MCP.md tool table: the table was stale after the label tool was added. I ran bun scripts/mcp-tools.ts to regenerate it and pushed the result as commit 56c23203. test/mcp-tools.test.ts passes locally (171 tests).
• Files-page timing test: "the Files page of a 40-file diff … stay under their ceilings" passes locally, 4 of 4. I didn't change anything for it. The PATCH labels change doesn't touch the diff page, so I think the failure was load on the shared check machine, not the code. The timing test is not confirmed fixed, so if the check fails it again, that points to a real problem.

I did not run bun x tsc --noEmit or the gate script this round, since the only change is the regenerated doc table.

I merged main into the branch and pushed it (35f0a40b). The only conflict was in docs/MCP.md.

I took main's copy of that file and regenerated it with bun scripts/mcp-tools.ts. The tool table is generated, so this keeps what both sides added. Regenerating kept the label tool's rows (the file still mentions labels).

bun x tsc --noEmit is clean and test/mcp-tools.test.ts passes (171 tests). I did not run the other tests or the gate script locally. The forge's check will run the full suite on this push.