This PR adds support for passing instantiated command objects (extending Symfony\Component\Console\Command\Command) directly to:

Schedule::command(...)
Artisan::call(...)

Why?

Currently, when working with Artisan commands, developers must pass either the command signature (a string) or the class name (e.g., TestCommand::class), which Laravel resolves from the container.

• A similar pattern exists in Schedule::job() method, which accepts either a job class instance or a job class name. If a class name is provided, Laravel resolves it from the container:

https://github.com/laravel/framework/blob/12.x/src/Illuminate/Console/Scheduling/Schedule.php#L179

• Laravel already supports working with actual command instances internally. For example, the call() method from the src/Illuminate/Console/Concerns/CallsCommands.php trait (used in the Illuminate\Console\Command class) allows this:

class TestCommand extends Command
{
  public function handle()
  {
      $this->call(new AnotherTestCommand);
  }
}

https://github.com/laravel/framework/blob/12.x/src/Illuminate/Console/Concerns/CallsCommands.php#L27

• Additionally, this behavior is supported in the parseCommand() method in src/Illuminate/Console/Application.php, which checks if the argument is a subclass of SymfonyCommand. However, this logic was not accessible through higher-level APIs like Artisan::call():

https://github.com/laravel/framework/blob/12.x/src/Illuminate/Console/Application.php#L177

Changes

Before:

Schedule::command(TestCommand::class);
Artisan::call(AnotherTestCommand::class);

Now also supported:

Schedule::command(new TestCommand);
Artisan::call(new AnotherTestCommand);