The issue was that after PR #1640 switched from closure-based deps to context-based deps,
the stdio server was missing middleware to inject ToolDependencies into the request context.
This caused tools to panic with "ToolDependencies not found in context" when called.

Added middleware in NewMCPServer() that wraps all requests with github.ContextWithDeps(),
ensuring deps are available to tool handlers via MustDepsFromContext().

Also added tests to verify server creation and toolset resolution logic.

Co-authored-by: SamMorrowDrums <4811358+SamMorrowDrums@users.noreply.github.com>

* add aliases for new actions tools

* generate docs

* Add raw client error annotation and annotate GetFileContents

* Track response.

* add raw errors to context

* add raw api error test

* Update pkg/errors/error.go

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Add blank line after Error() method for readability

* add NewGitHubRawAPIErrorResponse back

---------

Co-authored-by: Matt Holloway <mattdholloway@pm.me>
Co-authored-by: Matt Holloway <mattdholloway@github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Add DestructiveHint: true to the delete_project_item tool to be
consistent with other delete operations (delete_file and
delete_workflow_run_logs) that properly indicate destructive behavior.

This helps LLMs better understand that this tool permanently removes
data and should be used with appropriate caution.

Co-Authored-By: Claude <noreply@anthropic.com>

Add destructiveHint: true to the snapshot file to match the code change.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

* get_file_contents improvements

* Return custom errors when main ref is supplied

* Remove test for short sha

* Apply Copilot suggestion