/clear does not cancel a slash command queued behind it, and gives no warning

When a slash command is sitting in the queue (typed while the assistant was still working) and a /clear lands ahead of it, the /clear empties the conversation but the queued command still runs — now against a fresh, empty context rather than the conversation it was typed into.

Nothing warns the user this will happen. From the user's point of view they cleared the session, so a command they queued earlier feels cancelled; instead it fires into the new session, where it can do real work under different conditions than intended (observed with a workflow command that begins reading project state and acting on it).

Expected: either /clear cancels anything still queued behind it, or the UI warns that a queued command survives the clear and asks whether to keep it.

Actual: the queued command runs silently after the clear.

Adjacent but distinct: #76086 and #62349 request controls to clear queued prompts deliberately; this report is about /clear's interaction with an already-queued command and the absence of any warning.