Name based project fields

[veralizeth]

Summary

Let agents address Project v2 fields, single-select options, and item field values by name through the GitHub MCP server — both read and write, instead of pre-resolving node/database IDs. Resolution happens in the wrapper; the underlying GraphQL/REST mutation stays strongly ID-typed.

Why

No linked issue yet.

Today update_project_item accepts owner login, project number, and issue number, but the write still demands the field ID and item ID and does no option-name resolution. Reads are equally ID-bound: list_project_items returns only Title, so reading a field value requires a list_project_fields preflight to resolve the field ID first. This forces a multi-step list-and-filter dance, burns context, and invites mis-bound IDs.

This is a surfacing gap, not a platform gap — the GraphQL API already resolves names. We move resolution into the wrapper and keep the mutation ID-typed so a blind name pass-through fails loudly rather than corrupting data.

• Closes #3310 (opaque batch failure / structured-error theme tie-in)
• Token/COGS budget tracked per #3316
• Coordination: looping in copilot-mcp-core per #2978 (numbers below)

What changed

• Write by name (update_project_item): accept a field by updated_field.name, resolve the single-select option by name, and resolve the item by item_owner + item_repo + issue_number when item_id is omitted — then call the existing ID-typed mutation. {id} and {name} are mutually exclusive; passing both, or neither, fails with a clear error.
• Read by name (get_project_item, list_project_items): new optional field_names param resolved server-side to field IDs, so no list_project_fields preflight is needed.
• Structured, self-correctable errors (pkg/errors): new StructuredResolutionError (JSON body with error, name, candidates,
  hint) for field_not_found, field_ambiguous, option_not_found, option_ambiguous, item_not_in_project, wrong_field_type.
• New projects_resolver.go with name→ID resolution helpers + projects_resolver_test.go.
• Mutation stays ID-typed: resolved names are converted to the numeric databaseId before the REST/GraphQL call.

MCP impact

• No tool or API changes
• Tool schema or behavior changed
• New tool added

Prompts tested (tool changes only)

Security / limits

• No security or limits impact
• Auth / permissions considered
• Data exposure, filtering, or token/size limits considered

Schema (always-on) token delta measured with cl100k_base:

Source	Δ tokens
field_names on get_project_item	+61
field_names on list_project_items	+64
Growth on reused descriptions (updated_field +36, item_id +23, item_owner +14, item_repo +14, issue_number +12)	+99
Total always-on schema delta	≈ 224 tokens

Notes:

• This is the per-request schema cost added to any context that loads the projects_* tools (additive only; no existing params removed).
• Runtime / COGS: name-based calls add GraphQL round-trips only when the name params are used — field(name:) resolution fetches project fields (fields(first:100)), and issue-number item resolution adds a project-node-ID lookup + an issue.projectItems query. ID-based calls incur zero extra round-trips. Projected impact is bounded by name-based call volume, not total projects_* traffic.
• Measured with OpenAI cl100k_base; the production model tokenizer may differ
  by a few percent.

Tool renaming

• I am renaming tools as part of this PR (e.g. a part of a consolidation effort)
  • I have added the new tool aliases in deprecated_tool_aliases.go
• I am not renaming tools as part of this PR

Note: if you're renaming tools, you must add the tool aliases. For more information on how to do so, please refer to the official docs.

Lint & tests

• Linted locally with ./script/lint
• Tested locally with ./script/test

Docs

• Not needed
• Updated (README / docs / examples)