CVE-2026-31733: sched_ext: Fix stale direct dispatch state in ddsp_dsq_id

In the Linux kernel, the following vulnerability has been resolved:

schedext: Fix stale direct dispatch state in ddspdsqid

@p->scx.ddspdsqid can be left set (non-SCXDSQINVALID) triggering a spurious warning in markdirectdispatch() when the next wakeup's ops.selectcpu() calls scxbpfdsqinsert(), such as:

WARNING: kernel/sched/ext.c:1273 at scxdsqinsertcommit+0xcd/0x140

The root cause is that ddspdsqid was only cleared in dispatchenqueue(), which is not reached in all paths that consume or cancel a direct dispatch verdict.

Fix it by clearing it at the right places:

- directdispatch(): cache the direct dispatch state in local variables and clear it before dispatchenqueue() on the synchronous path. For the deferred path, the direct dispatch state must remain set until processddspdeferredlocals() consumes them.

- processddspdeferredlocals(): cache the dispatch state in local variables and clear it before calling dispatchtolocaldsq(), which may migrate the task to another rq.

- doenqueuetask(): clear the dispatch state on the enqueue path (local/global/bypass fallbacks), where the direct dispatch verdict is ignored.

- dequeuetaskscx(): clear the dispatch state after dispatchdequeue() to handle both the deferred dispatch cancellation and the holdingcpu race, covering all cases where a pending direct dispatch is cancelled.

- scxdisabletask(): clear the direct dispatch state when transitioning a task out of the current scheduler. Waking tasks may have had the direct dispatch state set by the outgoing scheduler's ops.selectcpu() and then been queued on a wakelist via ttwuqueuewakelist(), when SCXOPSALLOWQUEUEDWAKEUP is set. Such tasks are not on the runqueue and are not iterated by scxbypass(), so their direct dispatch state won't be cleared. Without this clear, any subsequent SCX scheduler that tries to direct dispatch the task will trigger the WARNONONCE() in markdirectdispatch().