Per-token FlowMatch Euler steps use the opposite velocity sign #15185

Describe the bug

FlowMatchEulerDiscreteScheduler.step reverses the deterministic velocity sign when per_token_timesteps is supplied. A zero sample with unit velocity and sigma changing from 1 to 0.5 should advance to -0.5, regardless of whether timesteps are scalar or per-token.

The shipped LTXCondition and SanaWM pipelines compensate by negating the model prediction. That preserves their deterministic updates, but supplies the wrong velocity to the stochastic clean-sample estimate x0 = sample - sigma * velocity.

PR #15177 corrects the scheduler sign and removes both caller compensations. External per-token callers using the old negation must remove it too.

Reproduction

import torch
from diffusers import FlowMatchEulerDiscreteScheduler

sample = torch.zeros(1, 2, 3)
velocity = torch.ones_like(sample)
for per_token in (False, True):
    scheduler = FlowMatchEulerDiscreteScheduler(shift=1)
    scheduler.set_timesteps(sigmas=[1.0, 0.5])
    kwargs = {"per_token_timesteps": torch.full((1, 2), 1000.0)} if per_token else {}
    result = scheduler.step(velocity, scheduler.timesteps[0], sample, **kwargs).prev_sample
    print("per_token =", per_token, ":", result.flatten().tolist())

Observed output

per_token = False : [-0.5, -0.5, -0.5, -0.5, -0.5, -0.5]
per_token = True : [0.5, 0.5, 0.5, 0.5, 0.5, 0.5]

Expected: both paths return six -0.5 values. The fixed code in #15177 does so.

System Info

Reproduced on CPU, Windows, Python 3.12.6, PyTorch 2.15.0+cpu, Diffusers 0.42.0.dev0. The failing run used the scheduler source from the parent of PR commit f7ccd23; the passing run used that PR commit. No GPU or generation-quality claim.

Assistance

Filed by an AI coding agent at the contributor's request, following the maintainer permission reported by the contributor. Human review: davrens101 confirmed reviewing the work live before submission. No independent maintainer approval of the fix is claimed.