[None][test] Add sparse MQA/GQA coverage and support documentation

[lfr-0531]

@coderabbitai summary

Description

Sparse MQA/GQA kernel support was introduced in #12470, and the sparse attention framework was subsequently unified in #12733. The internal token-sparse MQA/GQA path still lacked an explicit regression support matrix, while the sparse attention feature documentation did not distinguish this kernel capability from public sparse attention algorithms.

This PR:

• expands the existing sparse attention unit tests across MQA and GQA, BF16 and FP16, supported head dimensions (64, 80, 128, and 256), and the maximum query-head group size of 32;
• tightens the architecture gate to the SM100 family and ensures cache-manager resources are released on failures;
• documents the internal Sparse MQA/GQA kernel support matrix and its current limitations;
• reorganizes the sparse attention feature guide around selectors, compute backends, public algorithms, configuration, and capability comparison.

This is a test and documentation change only. It does not modify runtime behavior, public APIs, kernels, or performance. The PR is intentionally kept together because the tests are both regression coverage and the executable reference for the documented internal kernel contract.

Related PRs: #12470, #12733.

Test Coverage

• tests/unittest/_torch/attention/sparse/test_sparse_attention.py: 39 passed, 4 warnings on NVIDIA B200 (SM100) before the final rebase.
• Targeted pre-commit hooks for the two changed files: passed after the rebase.
• Python 3.12 syntax compilation and diff/DCO checks: passed after the rebase.
• A runtime rerun on the latest base is pending because the current shared test virtual environment no longer contains PyTorch.

PR Checklist

Please review the following before submitting your PR:

• PR description clearly explains what and why. If using CodeRabbit's summary, please make sure it makes sense.

• PR Follows TRT-LLM CODING GUIDELINES to the best of your knowledge.

• Test cases are provided for new code paths (see test instructions)

• If PR introduces API changes, an appropriate PR label is added - either api-compatible or api-breaking. For api-breaking, include BREAKING in the PR title.

• Any new dependencies have been scanned for license and vulnerabilities

• CODEOWNERS updated if ownership changes

• Documentation updated as needed

• Update tava architecture diagram if there is a significant design change in PR.

• The reviewers assigned automatically/manually are appropriate for the PR.

• Please check this after reviewing the above items as appropriate for this PR.

GitHub Bot Help

To see a list of available CI bot commands, please comment /bot help.