Generalize receiver analysis documentation

[DavidBakerEffendi]

Summary

• replace the static receiver-language support inventory with an adapter-neutral receiver-analysis contract
• make each input's runtime outcome and diagnostics authoritative for capability decisions
• align the capability guide, CodeQuery JSON/RQL references, tutorials, Python client docs, evaluation guidance, and public schema help

Why

Receiver tracking now consumes shared structured facts supplied by the selected adapter. A hand-maintained list of included and excluded languages can drift as adapters evolve and can imply stronger guarantees than a particular source form or workspace supports. The documentation now describes the stable contract and directs callers to inspect receiver_analysis outcomes, diagnostics, truncation, budgets, and available evidence.

Language-specific tutorials remain examples of the shared contract rather than defining its coverage.

User impact

Readers no longer need to reconcile duplicated receiver-support lists across documentation surfaces. They get one consistent rule: query the selected adapter and treat the returned structured outcome and diagnostics as authoritative for that input.

Follow-up #1132 tracks runnable Rust and Python library cookbook examples for query_code.

Validation

• npm run build — 57 pages and 5,383 internal links
• cargo test --test code_query_tutorials receiver_traversal_tutorial
• cargo fmt --all -- --check
• scripts/with-isolated-cargo-target.sh cargo clippy --all-targets --all-features -- -D warnings using the pinned Rust 1.96.0 toolchain
• git diff --check origin/master...HEAD
• visually inspected the rendered capabilities and receiver-traversal pages