Feature Request: Expose CloudFormation stack data on the lease API (outputs, provisioning progress & time estimates)

[chrisns]

Is your feature request related to a problem? Please describe.

When a lease is provisioned with a blueprint, there are a few points where useful
CloudFormation data isn't surfaced through the API:

1. During provisioning — the user sees a "Provisioning" status but has no
   visibility into how the deployment is progressing. For blueprints that take
   several minutes, this can feel like a black box.

2. After provisioning — the stack outputs (e.g. VPC IDs, endpoint URLs, IAM
   role ARNs) are available in the CloudFormation console within the sandbox account,
   but surfacing them through the API would remove the extra step of looking them up
   manually and make it easier to build automation on top of the provisioning workflow.

3. Region awareness — the lease holder may not know which region(s) the blueprint
   deployed into. Today they'd have to check with the admin or click through regions
   in the console to find their resources. Surfacing this alongside the outputs and
   progress would give them a complete picture without any guesswork.

4. No time expectation — when provisioning starts, there's no indication of how
   long it might take. Historical deployment durations are already recorded in the
   deployment history, but they aren't aggregated or surfaced to give users an
   estimate.

Describe the feature you'd like

1. Provisioning progress

While a lease is in the Provisioning state, expose resource-level progress on the
lease object so the UI (or API consumers) can show something like "3/27 resources
created" rather than just a spinner.

The check-deployment-status polling loop already runs every 30 seconds — it could
additionally call ListStackResources on the target account's stack to get the total
resource count and how many have reached CREATE_COMPLETE, then store a summary on
the lease:

{
  "status": "Provisioning",
  "provisioningProgress": {
    "regions": {
      "us-east-1": { "resourcesCompleted": 3, "resourcesTotal": 27 },
      "eu-west-1": { "resourcesCompleted": 12, "resourcesTotal": 12 }
    },
    "lastUpdated": "2026-02-28T14:30:00Z"
  }
}

The GUI could then poll GET /leases/{leaseId} on an interval and render a progress
bar. It wouldn't be perfectly linear (not all resources take the same time), but
even a rough indicator is a big improvement over no feedback at all. Breaking it down
by region also immediately tells the user where their resources are being deployed.

2. Stack outputs after provisioning

After a blueprint deployment succeeds, capture the CloudFormation stack outputs and
include them on the lease object returned by GET /leases/{leaseId}, keyed by
region:

{
  "status": "Active",
  "awsAccountId": "123456789012",
  "blueprintName": "Data Analytics Sandbox",
  "stackOutputs": {
    "us-east-1": [
      { "OutputKey": "VpcId", "OutputValue": "vpc-0abc123...", "Description": "Sandbox VPC" },
      { "OutputKey": "BucketName", "OutputValue": "my-sandbox-bucket-xyz", "Description": "S3 data bucket" }
    ],
    "eu-west-1": [
      { "OutputKey": "ApiEndpoint", "OutputValue": "https://api.example.com", "Description": "Regional API" }
    ]
  }
}

This also serves as a clear record of which regions were involved, so the user
doesn't need to hunt for their resources.

3. Estimated provisioning time (stretch goal)

The deployment history already records the duration of each blueprint deployment.
Aggregating this (e.g. a rolling average or median over recent successful deployments)
and surfacing it on the blueprint or lease would let the UI show something like
"This blueprint typically takes around 8 minutes to provision" when a deployment
starts.

This could live on the blueprint object itself (updated after each successful
deployment) and be copied onto the lease at provisioning time:

{
  "status": "Provisioning",
  "estimatedProvisioningMinutes": 8,
  "provisioningProgress": { ... }
}

Combined with the resource progress from (1), this would give users a much clearer
sense of where things stand — both "how far along" and "how long to expect."

Possible implementation path

• The deployment orchestrator already has cross-account role assumptions and
  CloudFormation SDK clients. The additional API calls (ListStackResources,
  DescribeStacks) would fit naturally into the existing polling loop and
  post-deployment flow.
• New optional fields on MonitoredLeaseSchema (following the same
  .nullable().optional() pattern used for blueprintId) would be returned
  automatically by the existing GET /leases/{leaseId} endpoint.
• The orchestrator's IAM policy would need cloudformation:ListStackResources
  and cloudformation:DescribeStacks added.
• For the time estimate, the DeploymentHistoryItem already stores duration —
  an aggregate (e.g. estimatedDeploymentMinutes) could be maintained on the
  blueprint record and recalculated after each completed deployment.

Additional context

The provisioning progress and time estimates would be especially helpful for
blueprints with longer deployment times (the configurable timeout goes up to 480
minutes). The stack outputs and region information would benefit automation workflows
that provision a sandbox via the API and then need to programmatically interact with
the deployed resources — for example, connecting a CI/CD pipeline to a freshly
provisioned VPC, or providing users with a direct link to a deployed application
endpoint without having to know which region to look in.