Add multi-project support via config file

[zdavis-rollbar]

Summary

• Users with multiple Rollbar projects previously had to install and run a separate MCP server instance for each project. This PR allows a single MCP server instance to be configured with multiple projects, each with its own access token and optional API base URL.
• Adds a .rollbar-mcp.json config file format supporting named projects. Config is resolved from a 4-source lookup chain (explicit env var path → cwd → home dir → existing ROLLBAR_ACCESS_TOKEN env var), so all existing single-project setups continue to work with zero changes.
• Adds a project parameter to all tools so the LLM can specify which project to target when multiple are configured. The parameter is optional when only one project is configured.
• Adds a new list-projects tool so the LLM can discover which projects are available without the user having to explain it.

[brianr]

Comments from Codex:

**Findings**
1. High: `get-replay` can return a `resource_link` that is unusable in the new multi-project mode. The tool always emits a `rollbar://replay/...` link in resource mode at [src/tools/get-replay.ts:113](/Users/brian/Development/rollbar-mcp-server/src/tools/get-replay.ts#L113), but the resource reader hard-fails whenever more than one project is configured at [src/resources/replay-resource.ts:109](/Users/brian/Development/rollbar-mcp-server/src/resources/replay-resource.ts#L109). In practice, `delivery="resource"` is broken for the main feature this PR adds.

2. Medium: Invalid `.rollbar-mcp.json` files are silently treated as “missing”, so the server can fall through to a lower-priority config source and target the wrong Rollbar project with no warning. `loadProjectsFromFile()` collapses parse/schema failures into `null` at [src/config.ts:75](/Users/brian/Development/rollbar-mcp-server/src/config.ts#L75), and `loadConfig()` then keeps falling back from cwd/home to other sources at [src/config.ts:127](/Users/brian/Development/rollbar-mcp-server/src/config.ts#L127) and [src/config.ts:133](/Users/brian/Development/rollbar-mcp-server/src/config.ts#L133). That is risky for read tools and especially for `update-item`.

3. Medium: The config parser can silently ignore a `projects` array and keep the server in single-project mode. The shorthand schema is permissive and checked first at [src/config.ts:25](/Users/brian/Development/rollbar-mcp-server/src/config.ts#L25) and [src/config.ts:83](/Users/brian/Development/rollbar-mcp-server/src/config.ts#L83), so any object with a top-level `token` parses as shorthand before the multi-project branch at [src/config.ts:96](/Users/brian/Development/rollbar-mcp-server/src/config.ts#L96) is reached. A migration like `{ "token": "...", "projects": [...] }` will therefore behave incorrectly instead of failing loudly.

**Residual Risk**
CI no longer runs the authenticated E2E path. The workflow stopped passing `ROLLBAR_E2E_READ_TOKEN` at [.github/workflows/ci.yml:47](/Users/brian/Development/rollbar-mcp-server/.github/workflows/ci.yml#L47), and the script now skips when that token is absent at [tests/e2e/test-get-item-details.sh:27](/Users/brian/Development/rollbar-mcp-server/tests/e2e/test-get-item-details.sh#L27). So the new auth/config plumbing is not exercised in GitHub Actions anymore.

Ran `npm test` and `npm run build`; both passed.

I'm OK with removing the e2e test for now. The others, I think should be fixed.

[zdavis-rollbar]

Updated based on feedback.

[brianr]

@claude review

[brianr]

@claude review