feat: add new tool to load mcp resources

[rodneyshibu]

Context
As part of our onboarding devx, we want to add a set of steps and instructions to help users integrate their existing projects with Neon. We added this get started guide. This will typically be run through an init command that sets up the MCP server for the user.

What changes are proposed in this pull request?
This PR adds a load_resource tool to expose guides (starting with our Get Started resource) to the agent via a MCP tool. This is useful for two reasons.

1. Some IDEs don't support MCP resources and only have access to MCP tools
2. MCP resources are typically less likely to be loaded into context by agents (unless we explicitly instruct the agent to use the MCP resource)

How was this tested?
Tested this by deploying to preview env

#LKB-6294

[orca-security-us]

Orca Security Scan Summary

Status	Check	Issues by priority
Passed	Infrastructure as Code	0   0   0   0	View in Orca
Passed	SAST	0   0   0   0	View in Orca
Passed	Secrets	0   0   0   0	View in Orca
Passed	Vulnerabilities	0   0   0   0	View in Orca

[github-actions]

🚀 Preview deployment ready: https://preview-mcp.neon.tech

[claude]

Code Review Summary

PR: #137 - Add new tool to load MCP resources
Files Changed: 4 files (+65, -4)
Review Focus: Architecture, Security, Logic, Testing

---

Review Statistics

• Files Reviewed: 4
• Lines Changed: 69 (65 additions, 4 deletions)
• Issues Found: 4
  • 🔴 Critical: 0
  • 🟡 Important: 3
  • 🔵 Consider: 1

---

Key Findings

Most Critical Issues:

1. [Testing] Missing Braintrust evaluation - The new load_resource tool lacks test coverage, which is required per CLAUDE.md guidelines. This is critical for ensuring the tool works correctly with LLM interactions.

2. [Logic] Insufficient error handling - Network errors from GitHub API will bubble up as generic errors without helpful context about which resource failed. This impacts debuggability in production.

3. [Logic] Limited error details - HTTP error responses only include status codes, missing status text and response body that could help diagnose issues like rate limiting or repository access problems.

What Looks Good:

1. ✅ Architecture Pattern - The tool follows the correct registration pattern: definition in NEON_TOOLS, Zod schema in toolsSchema.ts, handler in tools.ts, and proper typing with ToolHandlers
2. ✅ Error Handling Pattern - Uses InvalidArgumentError for invalid subjects, which is correctly handled by the server wrapper (server/errors.ts)
3. ✅ Analytics & Observability - No manual tracking needed; the server wrapper automatically tracks tool calls, meeting MCP-specific requirements

---

Notes

• ✅ Linting and build checks are automated by pr.yml workflow
• ✅ Analytics tracking is handled automatically by the server wrapper (no manual trackEvent calls needed)
• ✅ Error handling integrates with existing Sentry capture via server wrapper

The implementation is solid and follows project patterns correctly. The main gaps are around test coverage and error message quality for better debugging experience.