fix(fetch): retain PDF permits until parsing completes

[chaliy]

Motivation

• Prevent a denial-of-service vector where cancelling the async caller released a PDF-processing semaphore permit while the blocking pdf_inspector parse continued, allowing attackers to bypass the intended two-document concurrency cap.

Description

• Make the global PDF concurrency limiter a LazyLock<Arc<Semaphore>> so permits can be owned and moved into blocking tasks.
• Introduce run_pdf_task(...) which acquires an owned permit and executes the parser inside tokio::task::spawn_blocking while keeping the permit alive for the lifetime of the blocking closure.
• Update PdfProcessor::process to call run_pdf_task(...) and preserve existing parsing behavior and results.
• Add a regression unit test cancelled_pdf_caller_does_not_release_running_task_permit proving that aborting the async caller does not free the permit while the blocking parse runs, and update knowledge docs to reflect the cancellation-safe concurrency behavior.

Testing

• Ran cargo fmt --all -- --check and python3 scripts/check_okf.py knowledge, both succeeded.
• Ran targeted unit tests cargo test -p fetchkit cancelled_pdf_caller_does_not_release_running_task_permit and cargo test -p fetchkit pdf_processor, both passed.
• Ran full test suite with cargo test --workspace, documentation build RUSTDOCFLAGS='-D warnings' cargo doc --workspace --no-deps, and release build cargo build --workspace --exclude fetchkit-python --release, all succeeded.
• cargo clippy --workspace --all-targets -- -D warnings reported unrelated pre-existing clippy::collapsible_match findings in crates/fetchkit/src/convert.rs and thus failed; the clippy failures are not introduced by this change.

---

Codex Task