Every database command 400s in v0.5.0-v0.5.2: CLI sends include=schemas, API now requires include=databases

Description

As of v0.5.0 (still present in v0.5.2), every database-cluster:*, database-snapshot:* and database-restore:* command fails immediately with a 400:

In RequestExceptionHelper.php line 53:

  Bad Request (400) Response: {
      "message": "Requested include(s) `schemas` are not allowed. Allowed include(s) are `databases`."
  }

In RequestException.php line 115:

  Client error: `GET https://cloud.laravel.com/api/databases/clusters?include=schemas&page=1`
  resulted in a `400 Bad Request` response

The API no longer accepts include=schemas on /api/databases/clusters; it now allows include=databases. The CLI still sends schemas, so the cluster resolver 400s before any command reaches its actual work.

Root cause

include('schemas') is hardcoded in four places:

Because DatabaseClusterResolver is what every database command uses to turn a cluster name or ID into a DTO, the failure is not limited to database-cluster:list. Passing an explicit cluster ID does not help, since resolution still hits the same endpoint first. --json and --fields do not avoid it either.

Steps to reproduce

cloud database-cluster:list
cloud database-snapshot:list <cluster-id>
cloud database-restore:create <cluster-id> some-name --snapshot=<snapshot-id>

All three fail identically.

Verification that databases is the correct replacement

Patching the five call sites from include('schemas') to include('databases') in a local copy of the v0.5.2 phar makes every one of those commands work again, and the response still carries the schemas relationship the DTO reads:

$ php cloud database-cluster:list
[{"id":"db-…","name":"…","type":"laravel_mysql_84","status":"available",
  "config":{…,"uses_scheduled_snapshots":true,"retention_days":7},
  "schemas":[{"id":"db-schema-…","name":"production",…}]}]

So App\Dto\DatabaseCluster::createFromResponse() needs no change. Only the include parameter is wrong.

Environment

• laravel/cloud-cli v0.5.2 (composer global install), confirmed against the shipped phar
• PHP 8.4 / macOS (darwin 25.5.0)

Impact

There is currently no CLI path to any database operation, including listing clusters and creating or listing snapshots. Backup and restore workflows that use the CLI are blocked until the include parameter is corrected or the API accepts schemas again.

Suggested fix

Replace ->include('schemas') with ->include('databases') at the five call sites above.

Start with the five include('schemas') call sites listed in DatabaseClusterResolver.php, DatabaseClusterList.php, DatabaseClusterDelete.php, and EnvironmentUpdate.php. Reproduce with the database-cluster, database-snapshot, and database-restore commands, then verify the database commands no longer return 400 and that cluster responses still include schemas for the DTO.