phala cvms list: collapses to one entry per app, hiding replicas

[h4x3rotab]

phala CLI: `v1.1.13+62338ec`

Summary

When a phala_app has replicas > 1 (e.g. set via the
Phala Terraform provider
or via the API directly), phala cvms list only shows one row
per app — the primary CVM. The other replica CVMs are invisible
from the CLI even though they are running and have distinct CVM IDs.

To see all replicas of an app, you currently have to:

• query the API directly (/api/v1/apps/<id> returns the full
  cvms[] list), or
• inspect Terraform state (terraform state show phala_app.<n>
  prints cvm_ids = [...]).

This makes operating multi-replica apps (e.g. a Consul server
quorum, a Patroni postgres cluster) confusing — the CLI suggests
the cluster is undersized when it isn't.

Reproduce

# via the terraform provider
resource "phala_app" "x" {
  name = "demo-replicas"
  size = "tdx.small"
  region = "US-WEST-1"
  replicas = 2
  docker_compose = "services: { hello: { image: nginx } }"
  storage_fs = "zfs"
  wait_for_ready = true
}

After terraform apply:

$ terraform state show phala_app.x | grep cvm_ids -A 4
cvm_ids = [
  "05053901-1751-4572-8985-423dcb3b21db",
  "16d247ca-23f5-4ffa-b590-7f732eddbf51",
]

$ phala cvms list | grep demo-replicas
778f5393...   demo-replicas   running   4m
# only one row — the second CVM (16d247ca...) is hidden

Suggested fixes

Either:

• list all replica CVMs by default, with the app name shown once
  and the CVM IDs grouped, or
• add a --all-replicas / --show-replicas flag and document it
  prominently, or
• show a replicas: N column so it's obvious there are more CVMs
  than displayed.

The phala cvms get <app-id> command could likewise show the full
cvm_ids[] list for the app.

Impact

Found while prototyping a Consul cluster across CVMs and verifying
that replicas: 2 actually scaled. The CLI's silent collapse made
me think the apply hadn't done anything; only inspecting Terraform
state and the raw API confirmed the second replica existed.

Related

Phala-Network/terraform-provider-phala#5
(separate provider gotcha around storage_fs ForceNew, surfaced
in the same shakedown.)