[backport] Fix delete:true on issue fields — REST DELETE fallback (upstream main) #18

Summary

Fixes a silent no-op bug: when deleting the last (or only) issue field value, go-github's omitempty tag on IssueRequest.IssueFieldValues strips the empty slice from the PATCH body. The GitHub REST endpoint's if data.include?(ISSUE_FIELD_VALUES) guard then skips the whole block, leaving the field unchanged. The MCP tool reported success.

Fix: detect the empty-after-filter case in UpdateIssue and fire individual DELETE /repos/{owner}/{repo}/issues/{number}/issue-field-values/{field_id} requests per field as fallback. The DELETE endpoint is idempotent (404 for already-absent fields filtered out), and partial failures are accumulated and reported with per-field detail rather than short-circuiting.

New tests in pkg/github/issues_delete_test.go:

• Test_IssueRequest_EmptyFieldValues_OmittedByJSON — pins the omitempty contract
• The 1-of-1 fallback path
• The N-1 set-semantics path (non-empty kept list → PATCH alone)
• Test_UpdateIssue_DeleteAbsentFieldIsNoOp — already-cleared field is silent no-op
• Test_UpdateIssue_DeleteFallbackContinuesOnPartialFailure — partial failures aggregated

Upstream reference

• version: upstream main (post v1.4.0, unreleased)
• commits: github@29634da
• PR: Fix delete:true on issue fields by calling deleteIssueFieldValue mutation github/github-mcp-server#2755

Fork conflict

None. The fork does not have issue field write tools; this is in issues.go in the shared area.

Context

Agents using issue_write with delete: true on issue field values received a success response but the field was never cleared. This was invisible without checking the field state after the call, making it a hard-to-debug data integrity bug in automated workflows.