fix(security): bound ShadowSentinel hot-path DB reads with an explicit timeout

[bug-ops]

Summary

• ShadowSentinel::check_tool_call awaited two DB reads (get_trajectory, get_tool_history) on the pre-tool-dispatch hot path shared by every high-risk tool call (Shell/FileWrite/ExfilCapable/McpUnclassified) with no timeout — a stalled DB connection (e.g. a slow/unresponsive Postgres backend) could block dispatch indefinitely.
• Both reads are now wrapped in tokio::time::timeout, bounded by the existing probe_timeout_ms.min(2000) config value (no new config field). A timeout logs a warning and falls back to the same empty/partial result the pre-existing DB-error branch already produced — fail-open, matching ShadowSentinel's documented defence-in-depth contract.
• Extracted the trajectory + cross-session-history loading logic into a new private load_probe_context method to stay under clippy::too_many_lines after adding the timeout wrapping; behavior-preserving, verified line-by-line against the pre-fix code.
• Corrected a doc comment to state the true additive worst-case latency (2 * probe_timeout_ms.min(2000) + probe_timeout_ms, ~6s at defaults) rather than a misleading single shared ~2s bound.

Closes #6269

Test plan

• New regression test check_tool_call_falls_open_when_both_db_reads_stall: forces a genuine timeout via real SQLite pool exhaustion (max_connections(1) on :memory:), verifies both DB reads independently hit their timeout branch (both distinct warn logs fire) and check_tool_call still resolves fail-open with an empty trajectory despite real seeded data existing.
• cargo +nightly fmt --check
• cargo clippy --profile ci --workspace --all-targets --features "desktop,ide,server,chat,pdf,scheduler,testing" -- -D warnings
• cargo nextest run --config-file .github/nextest.toml --workspace --features "desktop,ide,server,chat,pdf,scheduler" --lib --bins — full suite green
• Rustdoc gate (RUSTFLAGS="-D warnings" RUSTDOCFLAGS="--deny rustdoc::broken_intra_doc_links") — clean, new intra-doc link resolves
• gitleaks protect --staged — no leaks
• Adversarial critique + code review completed, both approved