pdf-server: make tombstone-persistence e2e runnable (basic-host iframe-reload replay or URL-keyed storage)

The e2e test tests/e2e/pdf-incremental-load.spec.ts › annotation tombstone preservation is currently test.fixme (see #639). It guards the restoredRemovedIds union in mcp-app.ts persistAnnotations() — a deletion on an unvisited page must survive a persistAnnotations() triggered elsewhere after a viewer reload.

Why it can't run today: the load-bearing scenario needs a fresh viewer load that reads the same localStorage key as the prior session. The key is pdf-annot:${toolId}, and:

• inner-iframe location.reload() → basic-host doesn't re-postMessage the cached tool result, so the viewer never gets data
• a fresh display_pdf call → new toolId → new storage key → restore misses

Options (any one unblocks the test):

1. basic-host replays tool result on iframe onload (~10 lines in basic-host; benefits any MCP App that reloads its iframe).
2. URL-keyed annotation storage — annotationStorageKey() keys on the PDF URL (or a hash) instead of toolId. Annotations would survive across conversations for the same PDF, which is arguably the right product behaviour anyway.
3. Test-only addInitScript seed — one-shot localStorage.getItem shim returning the seeded diff for the first pdf-annot:* lookup. No prod changes; tests the real restoreAnnotations() → persistAnnotations() path.

The fix is currently covered by the computeDiff/serializeDiff contract tests in examples/pdf-server/src/pdf-annotations.test.ts, but those don't reach the DOM-coupled glue.

Start with tests/e2e/pdf-incremental-load.spec.ts and the annotation tombstone preservation case, then read mcp-app.ts persistAnnotations() and examples/pdf-server/src/pdf-annotations.test.ts. Compare the basic-host iframe reload behavior with the URL-keyed and test-only seeding options; done means the case is no longer test.fixme and passes through restoreAnnotations() and persistAnnotations().