refactor: use @heroku/sdk for pipelines commands

[eablack]

Summary

• Replace direct Platform API calls in pipelines (list), pipelines:create, pipelines:info (via disambiguate's UUID branch), pipelines:promote, pipelines:destroy, and pipelines:update with @heroku/sdk equivalents (pipeline.list/info/create/delete, pipelineCoupling.create/infoByApp/update, account.infoByUser, team.info, promotePipeline).
• Wire pipelines:promote to promotePipeline's onReleaseStream callback. The release-command output streaming logic that lived in this file (busl fetch with retry, single-target early-exit, release info lookup) now lives in the SDK; the CLI just pipes the resulting ReadableStream<Uint8Array> to process.stdout. Drops ~80 lines of poll/stream/2FA helpers.
• Drop the listPipelineApps wrapper from src/lib/api.ts and have its four consumers (info, diff, transfer, promote) import the new SDK composition directly. The AppWithPipelineCoupling type also moves to the SDK; render-pipeline.ts widens it locally with Record<string, unknown> to satisfy hux.table's row constraint. Removes the now-unused getAppFilter/listCouplings helpers and FILTERS_HEADER constant from lib/api.ts.
• Add a local PipelineCreateBody type that extends @heroku/types' PipelineCreateOpts with the undocumented generation field the API accepts but the heroku/api schema doesn't declare. Comment in source explains why.
• Expose Promote.promotePipeline as a static reference so tests can stub the SDK call without changing production code (mirrors the prior Cmd.sleep convention).
• Add tmp/**/* to the eslint ignore list (build artifacts were producing 138k unrelated lint errors).

Type of Change

• refactor: Refactoring existing code without changing behavior

Testing

Notes: Smoke-tested against real apps in the heroku-dev-tools team using a locally built CLI. Both promotion paths exercised: standard polling and the single-target release-command streaming path (the more complex behavior the SDK's onReleaseStream callback now drives). update and destroy exercised against the same pipeline.

Steps:

1. npm run build to compile the refactored CLI.
2. Create two staging/prod apps:

   heroku apps:create eb-sdk-test-staging --team heroku-dev-tools
   heroku apps:create eb-sdk-test-prod --team heroku-dev-tools
   

3. Build the pipeline using the refactored commands:

   ./bin/run pipelines:create eb-sdk-test-pipeline -a eb-sdk-test-staging -s staging -t heroku-dev-tools
   ./bin/run pipelines:add eb-sdk-test-pipeline -a eb-sdk-test-prod -s production
   ./bin/run pipelines:info eb-sdk-test-pipeline   # confirms the assembled pipeline (renders apps via SDK listPipelineApps)
   ./bin/run pipelines                              # confirms list output
   

4. Verify pipelines:update re-stages an app:

   ./bin/run pipelines:update -a eb-sdk-test-staging -s production
   ./bin/run pipelines:info eb-sdk-test-pipeline   # confirms eb-sdk-test-staging now shows in production
   

5. Seed the staging app with a release. POST /sources for a signed S3 pair, upload a small tarball containing a Procfile with both web: and release: processes (release script prints lines over ~10s so the streaming path is observable), then POST /apps/eb-sdk-test-staging/builds with the get_url. Wait for status succeeded.
6. Promote and observe the release-command output stream live to stdout:

   ./bin/run pipelines:promote -a eb-sdk-test-staging
   

   Expected output: Running release command... followed by the streamed step 1 / 10 ... step 10 / 10 lines emitted in real time, then Promotion successful and eb-sdk-test-prod: succeeded. This exercises HerokuApiClient.stream() → SDK onReleaseStream → stream.pipeTo(WritableStream) → process.stdout.
7. Verify pipelines:destroy removes the pipeline:

   ./bin/run pipelines:destroy eb-sdk-test-pipeline
   ./bin/run pipelines                              # the pipeline is gone
   

8. Cleanup: heroku apps:destroy for both apps.

Related Issues

GUS work item: W-22265744

[tlowrimore-heroku]

LGTM!