fix: prevent Agreement.uri from overriding MCP resource URI in getAgreements

[JayDS22]

Summary

Fixes #128

Problem

In server/handlers/mcp.ts, the getAgreements function built MCP content
objects by setting uri first, then spreading ...a (the full Agreement
database row) last. The Agreement row has its own uri field, so the spread
overwrote the MCP resource URI (apap://agreements/{id}) with the agreement's
data URI (resource:org.accordproject...). MCP clients could not resolve the
resource because they received the wrong URI scheme.

Additionally, spreading the entire row added unrelated database fields
(template, state, agreementStatus, etc.) to the content object, which
only expects { uri, mimeType, text }.

Fix

Removed the ...a spread from the contents mapping. The agreement data is
already serialized inside the text property. Placed uri last in the
object literal so the MCP resource URI always takes precedence.

How to test

1. Create an agreement in the database
2. Connect an MCP client and read apap://agreements
3. Before: content items have uri like resource:org.accordproject...
4. After: content items have uri like apap://agreements/1

Discord: jayds22

[github-actions]

This PR is stale because it has been open 15 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[JayDS22]

@github-actions unstale

[github-actions]

This PR is stale because it has been open 15 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[github-actions]

This PR is stale because it has been open with no activity. Remove the stale label or comment to keep it active. Only items with maintainer engagement are auto-closed.

[JayDS22]

@github-actions unstale

[niallroche]

this cannot merge with 153, I bring to bring the test file from #153's branch into this one

[JayDS22]

Sounds good. Happy to do the lift: I'll cherry-pick mcp.test.ts from #153's branch onto this one, add export to buildApiErrorMessage so the test imports it instead of redeclaring, and close #153 once this merges. Want me to push to this branch directly or open the change as a follow-up commit for your review?

[JayDS22]

Force-pushed a rebase onto current main (d9168ba → e13b77f). The branch was stale (based on af4c9a0, pre-#154/#171/#176), so the rebase also dropped unintended drift in templates.ts, workflow YAML, and lockfiles, that also explains the previous Windows 20.x failure (was npm ci failing on a stale lockfile in ~12s). Diff is now purely server/handlers/mcp.ts (+56/−14). Local jest green (39/39).

Heads-up on the new Windows red check, it's unrelated to this PR and pre-existing on main. The failure is in root npm run build at npx reslate build:

Error: spawn EINVAL                                                                                                                                                                      
at ChildProcess.spawn (node:internal/child_process:414:11)
at Object.<anonymous> (D:\a\apap\apap\node_modules\reslate\reslate.js:21:6)          

Classic Windows-Node spawn gotcha in reslate.js. Same job is red on main's current HEAD (95105f5, run 26512754891) and on the two prior main runs back to early May; Linux + macOS green on all of them. Happy to open a separate PR for it.

@niallroche @mttrbrts - could one of you approve the Build / Unit Tests matrix when you get a chance? Thanks.