Fix UniPCMultistepScheduler under a float64 default dtype

[DawnofGenX]

Fixes #14888

multistep_uni_p_bh_update and multistep_uni_c_bh_update build rks from the sigmas (float32) and append torch.ones(()), which takes the default dtype. Under torch.set_default_dtype(torch.float64), torch.stack(rks) promotes R to float64 while b stays float32, and the first torch.linalg.solve(R, b) raises:

RuntimeError: linalg.solve: Expected A and B to have the same dtype,
but found A of type Double and B of type Float instead

This happens whatever the dtype of the sample (float16, float32 and float64 all fail). DPMSolverMultistepScheduler, DEISMultistepScheduler and SASolverScheduler run under a float64 default dtype.

Change

torch.ones((), device=device) → torch.ones_like(h) at both sites, so the unit entry takes the dtype and device of the other rks entries.

Under the default float32 this is the same tensor as before: I compared 144 configurations (solver_order 1–3 × bh1/bh2 × the three prediction_types × Karras sigmas or not × predict_x0 × thresholding, 10 steps) against pristine main and all 144 outputs are bit-identical.

Test

test_default_dtype_float64 in tests/schedulers/test_scheduler_unipc.py, modeled on the existing test_fp16_support. It runs the 10-step loop under torch.set_default_dtype(torch.float64) across solver_order 1–3, both solver types and all three prediction types, asserting the output dtype and finiteness.

• Fails on main with the linalg.solve error above; passes with the fix.
• The file's tests: 61 passed. (test_compatibles and test_beta_sigmas fail on main too, with an unrelated ImportError from optional dependencies.)

Before submitting

• Did you use an AI agent to help with this PR? Yes.
  • Read the "Coding with AI agents" guide.
  • Ran the self-review skill on the diff — notes below.
  • Self-review notes shared here.
• Read the contributor guideline.
• Read the philosophy doc.
• Discussed in issue UniPCMultistepScheduler fails in torch.linalg.solve under a float64 default dtype: the unit entry of rks takes the default dtype #14888.
• No documentation changes needed — this is an internal dtype fix with no API change.
• Added a regression test.

Self-review notes

Ran against .ai/references/review-rules.md.

Blocking issues: none.

Non-blocking issues: none.

Copied code: neither call site is inside a # Copied from block (the nearest markers in scheduling_unipc_multistep.py are at lines 711 and 1099), so no make fix-copies propagation is required.

Scope: grep -rn "torch.ones((), device=device)" src/diffusers/schedulers/ returns only these two sites, so no other scheduler carries this pattern. DPMSolverMultistepScheduler, DEISMultistepScheduler and SASolverScheduler were checked and already run under a float64 default dtype.

Dtype impact: the fix is a strict narrowing of the unit entry's dtype to match its neighbours. Under the default float32 the tensor is unchanged (144/144 configurations bit-identical), so there is no precision regression on the existing path.