[Bug] pa app add flow binds to a non-portable connection — flow bindings aren't restored when the Code App is redeployed to a new environment

[Lgsusjp]

Describe the bug

Unlike pa app add data-source, which supports --connection-ref <name> --solution-id <id> to bind through a solution-portable Connection
Reference, pa app add flow has no equivalent option. It always creates a
raw, environment-specific connection for the flow. As a result, a Code
App's Power Automate flow bindings are not portable across environments
the way its other data sources are — moving/redeploying the Dataverse
solution and Code App to a new environment does not restore them, and
pa app push doesn't warn that anything is missing.

Steps to Reproduce

1. Initialize a Code App in a Dev environment, add a flow with
   pa app add flow --flow-id <dev-flow-id>, and pa app push.
2. Export the Dataverse solution (tables, the flow, its own connection
   references) from Dev and import it into a new environment (UAT/Prod),
   either natively or via Power Platform Pipelines. Reconnect the
   solution's own connection references as prompted.
3. Push the Code App to the new environment — either interactively, or
   non-interactively as a service principal (pa app push --non-interactive) — reusing the same committed power.config.json.
   The push reports success.
4. Open the Code App in the new environment's maker portal and check the
   Flows tab.

Expected behavior

Either the flow binding is restored automatically (e.g. resolved by the
flow's portable workflowIdUnique against the new environment), or the
push fails / warns clearly that the flow connection couldn't be resolved
in the target environment.

Actual behavior

The push succeeds silently. The app's Flows tab reads "There are no flows
used in this app," because the committed power.config.json's
connectionReferences for the flow still reference the source
environment's (Dev's) connection, which doesn't exist in the target
environment.

The only documented fix
(https://learn.microsoft.com/en-us/power-apps/developer/code-apps/how-to/add-flows)
is to rerun pa app add flow --flow-id <id> once per flow, interactively,
authenticated against each target environment, and keep a separate
power.config.<env>.json per environment.

We also confirmed this step can't be moved into CI/CD: the
service-principal doc
(https://learn.microsoft.com/en-us/power-apps/developer/code-apps/how-to/use-service-principal)
only documents SP auth for pa app push, never for pa app add flow /
pa app list-flows; the add-flows page phrases the access requirement as
"the person who runs pa app add flow must have access to the flow
and its underlying connections," which reads as user-account-only.

Screenshots or Error Messages

N/A — no error is raised; the maker portal's Flows tab is simply empty in
the target environment after a successful push.

Environment information

• Framework, build tool or relevant package used: React + TypeScript +
  Vite, @microsoft/power-apps-cli (pa) v1.x
• Any connection/components: Power Automate solution-aware instant flows
  (Power Apps trigger) via the shared_logicflows connector; also
  Microsoft Dataverse and SharePoint Online data sources (unaffected,
  since those use portable Connection References)

Additional context

This is the one manual, human-in-the-loop step left in an otherwise fully
automated multi-environment CI/CD pipeline (Build → Dev → UAT → Prod via
Azure Pipelines with service-principal auth). Two possible fixes:

1. Add --connection-ref/--solution-id support to pa app add flow,
   mirroring pa app add data-source, so the flow binding can be made
   solution-portable.
2. Support (and document) running pa app add flow /
   pa app list-flows under service-principal authentication
   (PA_CLI_USE_SP_AUTH), so this step can be automated in a pipeline
   instead of requiring an interactive maker login per environment.

Happy to share our power.config.<env>.json setup and pipeline YAML
(Azure DevOps) if useful for reproduction.