Remove unnecessary FlashInfer top-k fallback (environment issue, not a CUDA 13 bug)

[oceanplexian]

What

Drops the try/except torch.topk fallback in _topk from #1, and types the
config parameter as Qwen3Config to match the base class signature.

Why

#1 added the fallback because FlashInfer 0.6.17's radix top-k failed to
JIT-compile on the ai-5xx server (CUDA 13). Root-caused since: the failure was
an environment issue, not a CUDA 13 incompatibility. The venv was using

export CPATH="$VENV/lib/python3.10/site-packages/nvidia/cu13/include"

so FlashInfer's JIT picked up a mismatched host_runtime.h from that include
tree. Symlinking curand*.h into the system include path instead (dropping the
CPATH override) lets the radix top-k compile and run correctly on CUDA 13 —
verified on the same dual-3090 box.

Since FlashInfer works once the include path is fixed, the fallback is
unnecessary — and actively harmful, since it catches bare Exception and
permanently disables FlashInfer top-k based on an environment misconfiguration,
masking real errors.

Note on the upstream PRs

• The LM-head guard fix (accept UnquantizedLinearMethod for a
  ParallelLMHead) is a real bug and is upstreamed as
  [Bugfix][Spec Decode] DFlash2: accept unquantized linear LM heads in the candidate selector vllm-project/vllm#52883, stacked on the DFlash2 base PR
  [Spec Decode] DFlash2: local convolution + candidate selector vllm-project/vllm#52816.
• The FlashInfer fallback was not upstreamed, for the reasons above. This
  PR aligns this fork's file with what is actually being proposed upstream.
• The correct deployment fix for the ai-5xx box is the symlink/include-path
  change, not a code fallback.

Test plan

• ruff check / ruff format --check on the touched file → clean
• Re-run the Add DFlash2 spec-decode model: fix unquantized LM head guard + FlashInfer top-k fallback #1 repro (INC-int4 Qwen3.8-27B target, DFlash2 drafter, TP2) after
  the server picks up the fixed FlashInfer kernel