What does this PR do?

Fixes #12771 — DPMSolverMultistepScheduler crashes with IndexError: index N is out of bounds when using beta_schedule='squaredcos_cap_v2' with use_karras_sigmas=True (or use_lu_lambdas=True).

Root cause

With the cosine (squaredcos_cap_v2) noise schedule, the sigma-to-timestep mapping (_sigma_to_t) produces many nearly identical float values near the end of the schedule (e.g., 998.90, 998.80, 998.70...) that collapse to the same integer timestep (998) after casting to int64. The current code intentionally skips rounding for cosine schedules, but this only defers the problem — values like 998.9 and 998.8 still become 998 when converted to int64.

These duplicate timesteps cause index_for_timestep to return incorrect indices, making step_index drift past the sigmas array bounds, crashing at self.sigmas[self.step_index + 1].

Fix

1. Round timesteps unconditionally — remove the squaredcos_cap_v2 exception for karras/lu sigma paths, since rounding is now handled centrally
2. Deduplicate timesteps after rounding — keep only the first occurrence of each unique value, preserving order
3. Filter sigmas to match the deduplicated timesteps
4. Update num_inference_steps to reflect the actual number of unique steps

This mirrors the existing deduplication logic already present in DPMSolverMultistepInverseScheduler (lines 358-359).

Test results

Note: The reduced step count (e.g. 20 → 12) is expected. With cosine schedules, many karras sigmas map to nearly the same timestep, so those steps were effectively redundant. The sigmas array is filtered to match, so the solver still uses the correct sigma values for each unique timestep.

Who can review?

@yiyixuxu (who engaged with the original issue)