CQRS is a rather broad pattern, meaning that it can be implemented in any number of ways. It's really about separating your read and write models and designing each of those models in a way that optimizes and simplifies their usage separately.
For your specific questions, I don't think there is a definitive answer. However, there are pros and cons to each approach.
Internal vs. External Commands
For example, if you were to treat the internal and external commands the same, then it removes a dual path problem where you process "tasks" differently than you process "commands". If everything is a command or event, then those make sense to anybody else being introduced to the project. Introducing "tasks" increases the cognitive load of someone reading the code, and you need to determine if creating that separation is worth the additional complexity.
When deciding between different options of a solution, I would refer you to A Philosophy of Software Design by John Ousterhout. In that book, he describes 3 symptoms of software complexity, and these include "change amplification", "cognitive load", and "unknown unknowns". I see your suggestion to introduce "tasks" as potentially leading to change amplification and cognitive load. It leads to change amplification because anything you change to the way commands are processed will need those same changes to process tasks. It increases cognitive load because there is now a new concept that a developer must understand (i.e. "tasks").
With that said, I could easily argue the other way. Since there are inherent differences in the way "commands" and "tasks" behave (i.e. synchronous vs asynchronous in your example), then trying to fit them into the same bucket is difficult and misguided. This can also lead to additional complexity because we're trying to treat two different concepts as the same thing which also increases cognitive load.
My point is that you can make your solution work either way and there isn't one solution that is a silver bullet. Each decision has a tradeoff and what makes a good software engineer is understanding what those tradeoffs are, articulating those tradeoffs to stakeholders and other developers, and then making a decision to move forward.
Saga Pattern
Your question about the Saga pattern is a little more concrete. First off, you're right that the saga pattern is about performing a sequence of commands. However, there's a couple key points I think you're missing. Sagas are usually for executing commands across multiple aggregates (it's not clear if you're dealing with multiple aggregates in your example). Also, it's about executing those commands in a transactional manner — meaning that all the commands succeed, or if one command fails, then compensating commands are executed to "undo" the saga.
This can be done in a couple ways. In the book Building Event-Driven Microservices by Adam Bellemare, he talks about a couple ways to carry out a sequence of commands in a transactional manner. Adam covers this topic as it relates to microservices, but the same patterns can be used in a single service using CQRS. In that book, Adam talks about choreographed and orchestrated workflows.
A choreographed workflow is similar to what you describe. It's a sequence of commands that occur without a single entity inherently controlling it. Each command is processed independently — it only cares about what event triggers it and what events result from it. In case of an error, it works similarly. An error event could be raised and then compensating commands could result from that error event. In a choreographed workflow, there's likely no formal representation of a Saga in code.
On the other hand, an orchestrated workflow is a more formal representation of the sequences of commands/events that happen. In this pattern, an orchestrator keeps track of the current state of the workflow, listens to the message bus, and dispatches new commands when others finish. It controls the sequence and also handles the rollback when an error occurs. In this case, the orchestrator is the representation of your "saga".
In my experience, choreographed sagas are fine for simple use cases such as invoking one command as a result of an event. When you need additional use cases such as cross-aggregate validation, complicated rollback, time-based triggering, etc. then using an orchestrated saga makes more sense.
