`AutoTuner.choose_one` iterates through every `OptimizationProfile` that
`_generate_optimization_profiles` produces from the `tuning_config`'s
bucket grid.  For each profile the method called
`_prepare_input_tensors(p, inputs)` *before* checking the cache.  On a
cache hit those freshly-synthesized tensors were discarded and the
cached (runner_id, tactic) pair was returned as-is.

Under normal serving this waste was invisible -- each `_prepare_input_tensors`
call launches only a handful of small `torch.rand` / `torch.randint` /
`torch.empty` kernels (one per `DynamicTensorSpec`) and produces the
right answer.  But any caller that runs `choose_one` repeatedly from
inside an `autotune(True)` context pays the full synthesis cost on
every forward, even once the cache is fully warm.

`benchmarks/bench_moe_deepseek.py` is the motivating example: its
`run_benchmark` wraps both the pre-warm (which populates the cache) and
the measured `bench_gpu_time` iters in a single `autotune(True)` scope
(intentionally, to share the same call-site for tactic selection and
timing).  Every subsequent forward re-entered the tuning-mode branch of
`choose_one`, re-synthesized tensors for all tuning buckets, and those
synthesis kernels were captured by CUPTI/nsys tracing of the
measurement region.  On DeepSeek-V3 at bs=128 on B200 this added
~360 us/forward for the CuteDSL backend and ~470 us/forward for
TRTLLM (the two backends' `dynamic_tensor_specs` differ).  The result
was both a ~3x inflation of per-forward timings and, because the tax
is asymmetric across backends, a visible inversion of the reported
ranking.

Fix: move the `search_cache` call above `_prepare_input_tensors` in the
tuning-mode loop.  On a cache hit (by far the common case once the
first iteration has populated the cache) we skip synthesis entirely.
On a cache miss we proceed exactly as before.  The lookup now passes
the caller's `inputs` rather than the synthesized `tensors`; this is
safe because `_get_cache_key` only uses `p.get_opt_shapes()` (the
profile's bucket shapes, independent of any particular input tensor)
plus `runner.get_cache_key_extras(inputs)`, and the documented
contract for `get_cache_key_extras` is to return properties like
dtype that are preserved by the synthesis initializers.  The
non-tuning-mode branch of `choose_one` and the final post-loop
`search_cache` call already use the caller's `inputs`, so this aligns
the in-loop lookup with both.

No behavior change on cache miss.  No change to how entries are stored
in `profiling_cache` (still keyed on `get_cache_key_extras(tensors)`
because `tensors` only exists on the miss path, which matches the
non-tuning-mode cache key under the contract described above).

Measured impact on `benchmarks/bench_moe_deepseek.py`, bs=128, EP=8,
B200, CUPTI enabled:
  - Before: CuteDSL 0.516 ms, TRTLLM 0.613 ms -> CuteDSL "wins" 1.19x
  -  After: CuteDSL 0.157 ms, TRTLLM 0.142 ms -> TRTLLM wins 1.11x

The post-fix ratio matches the ratio observed when timing via CUDA
events (`--no-cupti`: 0.144 / 0.126 = 1.14x TRTLLM), which bypasses
CUPTI and was therefore always clean of this pollution.