Move provider SDK dependencies out of Workflow core

[intel352]

PR #421 is a useful signal: Workflow core still directly depends on github.com/digitalocean/godo, which means core owns provider SDK drift that should belong to provider/plugin repos.\n\nDesired boundary:\n- Workflow core: IaC/provider interfaces, typed contracts, plugin loading, state/diff/apply orchestration, generic wfctl UX.\n- workflow-plugin-digitalocean: godo dependency, DO App Platform spec mapping, DO registry credential handling, DO read/diff/apply behavior.\n- Other provider SDKs should follow the same rule unless the dependency backs an intentionally built-in non-IaC core feature.\n\nInitial audit points from current main:\n- module/platform_do_app.go imports github.com/digitalocean/godo.\n- go.mod carries github.com/digitalocean/godo directly.\n- AWS SDK deps may be justified for built-in RBAC/secrets surfaces, but should be audited separately from IaC providers.\n\nAcceptance sketch:\n- Workflow core no longer imports godo for IaC/App Platform behavior.\n- Existing DO App Platform behavior is available through workflow-plugin-digitalocean.\n- wfctl errors remain actionable when a provider plugin is missing.\n- Dependabot provider SDK bumps target the provider repo, not Workflow core.

[intel352]

Additional examples from current Dependabot queue show the same boundary concern:\n\n- #419 bumps github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 in Workflow core.\n- #400 bumps github.com/aws/aws-sdk-go-v2/service/kinesis in Workflow core.\n- #421 bumps github.com/digitalocean/godo in Workflow core.\n\nSome AWS dependencies may still be justified by built-in non-IaC surfaces such as RBAC or secrets, so this should be an audit rather than a blind removal. The important rule is: IaC/provider SDKs used only for provider implementations should move to the relevant provider/plugin repos; Workflow core should keep generic interfaces, plugin loading, state/apply orchestration, and actionable missing-plugin errors.

[intel352]

Follow-up on #419/#400:\n\n- #419 is a direct elasticloadbalancingv2 bump. Main imports it from platform/providers/aws/drivers/alb.go and tests, plus AWS platform surfaces under module/platform_*. This is provider implementation code living in Workflow core, so it belongs in the provider-boundary migration scope.\n- #400 is an indirect kinesis bump. I do not see a direct service/kinesis import in current core code outside module metadata/docs, so this PR is mostly a symptom of the broader AWS SDK dependency graph being pulled into Workflow core by other AWS provider/S3/IAM surfaces. It should not be treated as a standalone Kinesis feature, but it should disappear from core once AWS provider implementation deps move to provider/plugin repos, except for any intentionally built-in non-IaC features we decide to keep.\n\nRecommendation: keep #419/#400 tracked under this issue instead of fixing them as one-off Dependabot PRs. The actual fix is to move provider-owned implementations/dependencies out of core, then Dependabot will target the provider repo/module that owns each SDK.