[PubMed MCP/Plugin] find_related_articles ignores max_results for link_type="pubmed_pubmed"

### Summary
`find_related_articles` ignores the `max_results` parameter for `link_type="pubmed_pubmed"`: the full ELink similar-articles set is always returned regardless of the value passed.

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

### Reproduction
Source PMID `31978945`, `link_type="pubmed_pubmed"`, varying `max_results`. Count the entries in `linksetdbs[0].links`:

| Call | `max_results` | links returned |
|------|---------------|----------------|
| 1 | 3 | 85 |
| 2 | 5 | 85 |
| 3 | 50 | 85 |
| 4 | (omitted) | 85 |

All four calls return the identical 85-entry list, so `max_results` has no effect — it is not applied as a cap, and
the value passed is irrelevant.

### Expected
At most `max_results` linked items returned (server-side or client-side slicing of the ELink result).

### Scope
- Confirmed for `link_type="pubmed_pubmed"` (the similar-articles list, which is the case where a cap actually matters).
- For `link_type="pubmed_pmc"` the result set for a single source PMID is inherently tiny (the article's own PMC full-text version, e.g. 1 link), so capping cannot be observed there — that is *not* evidence that `max_results` works for `pubmed_pmc`, only that the set is smaller than any cap.

### Impact
Oversized responses (token cost, truncation risk) and a documented parameter that is silently ignored. Easy to work around with client-side slicing, but `max_results` should be honored.