feat: add native Zotero Local API resolution

[KumamuKuma]

Summary

• add a private, read-only Zotero Local API v3 client using only the Python standard library
• resolve DOI, arXiv, title, and exact item-key inputs against the local personal library before web providers
• safely reuse local PDF attachments and expose auto, off, and required lookup policies through the resolver and pipeline
• report Local API readiness in the existing environment diagnostics and document the built-in workflow in English and Chinese

Resolution behavior

• auto (default): prefer a unique local match; fall back to existing providers for title, DOI, and arXiv misses
• off: make no Local API request and preserve the previous resolution path
• required: require a unique Zotero match, while trusted JSON artifacts and explicit local PDFs remain authoritative
• ambiguous local identities and unverifiable explicit Zotero keys fail closed
• missing or ambiguous attachments do not invalidate uniquely confirmed parent metadata
• group-library select links are rejected explicitly rather than being queried against the wrong library

Safety

• fixed loopback-only endpoint with proxies and redirects disabled
• read-only GET requests, no API key, no SQLite access, and bounded response sizes
• strict local file:// validation rejects remote UNC paths, ports, queries, fragments, invalid UTF-8, and encoded NULs
• attachment keys remain distinct from parent bibliographic item keys

Testing

• python -m pytest -q — 756 passed, 1 skipped
• Ruff passed for all changed Python implementation and focused test files
• git diff --check origin/develop...HEAD

[917Dhj]

Thanks for the substantial contribution — the Local API integration, safety boundaries, documentation, and test coverage are thoughtfully implemented.
Before merging, I found three identity-safety issues that need to be addressed:

1. Fuzzy title matching can accept a wrong paper as the canonical Zotero identity. For example, Deep Learning for Cats matches Deep Learning for Dogs at the current 0.84 threshold. Non-exact title matches need independent author/year evidence or should fail closed.
2. When a Zotero item has no DOI, title-based web enrichment can attach a DOI from a different same-title paper and replace the final paper_id. Strong identifiers should only be backfilled after author/year validation.
3. A malformed attachment URL can make urlsplit() raise an uncaught ValueError, causing an already-confirmed parent item to fail. Attachment URL errors should be converted to zotero_unsafe_file_url while preserving the parent metadata.
   The macOS and Windows CI checks pass, so these are behavioral edge cases rather than general test failures. Once these three cases are fixed with regression tests, I’d be happy to review the update.

[KumamuKuma]

@917Dhj Thanks for the detailed review. I’ve addressed all three identity-safety issues in separate commits:

44807e4 — Title-based Zotero lookup now requires an exact normalized title match, preventing fuzzy matches such as “Cats” vs. “Dogs”.

d4fb86f — Strong identifiers from title-based web enrichment are accepted only after title, leading-author, and publication-year validation.

ea44e4d — Malformed attachment URLs are converted to zotero_unsafe_file_url without discarding the already-confirmed parent metadata.

I also added regression tests for each case. The local suite passes with 761 passed, 1 skipped, and both the macOS and Windows CI jobs are green.