Support wait-until-ready semantics for async resource provisioning

Problem

When creating resources via external APIs, the POST response often contains provisional/incomplete state. For example, creating a DigitalOcean Load Balancer returns:

{
  "id": "d8624a18-...",
  "ip": "pending",
  "status": "new"
}

This snapshot is stored as the resource data. Any downstream CEL expression referencing data.latest("web-lb", "...").attributes.ip gets the string "pending" — not the actual IP that becomes available minutes later.

The current workaround is to create a separate "sync" workflow that calls get on each resource after deployment to refresh state. But this is manual, error-prone, and the user has to guess when the resource is ready.

Real-world impact

After deploying a full stack (VPC + droplets + LB + firewall), every resource's stored data is a creation-time snapshot. Getting usable values (IPs, final status, provisioned attributes) requires:

1. Waiting some unknown amount of time
2. Manually running get on each resource
3. Checking if the values are populated yet
4. Repeating if still pending

For a workflow with 5 resources, this turns a 45-second deployment into a multi-minute polling loop.

Proposed solution

Add optional wait-until-ready semantics to model methods:

Option A: Method-level waitFor configuration

Extension models could declare a readiness condition on their create method:

create: {
  waitFor: {
    poll: "get",           // method to call to refresh state
    condition: (data) => data.status === "active",
    interval: 5000,        // poll every 5s
    timeout: 300000,       // give up after 5min
  }
}

Option B: Workflow-level wait step

A workflow step type that polls until a condition is met:

- name: wait-for-lb
  task:
    type: wait
    modelIdOrName: web-lb
    method: get
    condition: ${{ self.result.attributes.status == "active" }}
    interval: 5
    timeout: 300

Option C: sync method convention

A simpler approach — extension models could implement a sync method that calls get and overwrites the stored data. Combined with #618 (idempotent create), a re-run of the workflow after provisioning would naturally refresh state.

Summary

Changes would be needed in:

• Method execution service — add optional post-execution polling loop
• Extension model SDK — expose waitFor configuration in method definitions
• Workflow step executor — support wait/poll step type or post-step sync
• Data writer — update stored data on each poll iteration so downstream references resolve to fresh values