[PubMed MCP/Plugin] lookup_article_by_citation swaps `pmid` and `key` fields in the response

### Summary
`lookup_article_by_citation` returns the resolved PMID in the `key` field, while the `pmid` field instead contains the caller-supplied tracking `key`. The two fields are swapped, so a client that reads `pmid` (as documented) gets the tracking key, not the PMID.

### Server
- Endpoint: `https://pubmed.mcp.claude.com/mcp`
- `serverInfo`: `{"name":"pubmed-mcp-server","version":"1.0.0"}`
- MCP protocol: `2025-06-18`

### Tool call (input)
```json
{
"name": "lookup_article_by_citation",
"arguments": {
"citations": [
{"journal": "N Engl J Med", "year": 2020, "volume": "382",
"first_page": "727", "author": "Zhu", "key": "myref-1"}
]
}
}
```
Reference article: Zhu et al., NEJM 2020 — PMID 31978945.

### Actual output
```json
{"citations":[{"journal":"N Engl J Med","year":"2020","volume":"382","first_page":"727","author":"Zhu","pmid":"myref-1","key":"31978945"}]}
```
So `pmid = "myref-1"` (the input tracking key) and `key = "31978945"` (the real PMID).

### Expected output
```json
{"citations":[{ "...": "...", "pmid":"31978945", "key":"myref-1"}]}
```

### Likely root cause
NCBI ECitMatch echoes the input citation string with the caller `key` and appends the resolved PMID as the final pipe-delimited field (`journal|year|volume|first_page|author|key|PMID`). It looks like the parser assigns the trailing PMID to `key` and the echoed input `key` to `pmid` — i.e. the last two fields are mapped in reverse.

### Impact
High for any anti-hallucination / citation-resolution workflow: a client that trusts `pmid` associates the wrong identifier (or an empty value) with a reference. The data is present, just under the wrong field name.