refactor: use @heroku/sdk for addons commands

[eablack]

Summary

Migrates addons:, maintenance:, and (as a consequence of rebasing onto feat/heroku-sdk-integration) pipelines: commands to use @heroku/sdk's new HerokuSDK + extensions architecture from sdk PR #25 / #26 / #27.

Migrated commands:

• addons (list) — addOn.list/listByApp + addOnAttachment.list/listByApp. Accept-Expansion is scoped via withHeaders to the app-scoped list only (the global /addons endpoint rejects it).
• addons:info — addOn.describe. The SDK scopes the Accept-Expansion header to the resolve call only (the /addons/:id/addon-attachments endpoint uses Accept-Inclusion, not Expansion).
• addons:create — addOn.createAndWait. Confirmation-required handling, polling-on-wait, and provisioning-failed errors now live in the SDK; the CLI hooks onProvisioning to preserve the two-phase status display ("Creating ... " → "Waiting for " → "Creating ... done"). The SDK also bakes in Accept-Expansion: addon_service,plan and X-Heroku-Legacy-Provider-Messages: true so the response includes the price for the action stop line and the provider's provision_message.
• addons:upgrade — addOn.upgrade (onResolved callback drives the action line; bare plan name auto-qualifies via the SDK).
• addons:services — addOnService.list.
• addons:plans — addOn.listPlans. Native contract+cents sort replaces the lodash sort.
• addons:rename — addOn.info + addOn.update (forwards the addon's current plan unchanged to satisfy the schema's plan required field).
• addons:detach — addOnAttachment.infoByApp + addOnAttachment.delete + release.list (Range header via withHeaders).
• maintenance (status / on / off) — app.info, app.enableMaintenance, app.disableMaintenance.
• pipelines:info, pipelines:diff, pipelines:transfer, pipelines:promote — migrated from @heroku/sdk/compositions/pipeline (which no longer exists) to pipelineCouplingExtensions.listApps and the standalone promotePipeline function. Promote.promotePipeline is kept as a static reference so existing sinon stubs continue to work.

Helper migrations:

• lib/addons/create-addon.ts — orchestration moved into the SDK's addOn.createAndWait. Helper is now a thin UX wrapper.
• lib/addons/addons-wait.ts — waitForAddonProvisioning migrated to the SDK polling path; waitForAddonDeprovisioning still uses legacy APIClient (used by deferred addons:destroy).
• data:pg:create, data:pg:fork, data:pg:migrate, addons:wait — call-site signature follow-through (no more this.heroku first arg to createAddon).

Drops:

• legacy lib/addons/resolve.ts dependency from addons:upgrade in favor of the SDK's typed AddonAmbiguousError.

Deferred to follow-up PRs (each has a single sticky API call not modeled in the SDK route registry):

• addons:destroy — needs body: {force} on DELETE.
• addons:attach — needs the /addons/:name/config/:namespace credential-config path variant.
• addons:wait, addons:docs, addons:open — fully migratable, just out of scope for this PR.

Test fixture updates:

• nock body matchers for POST /apps/:app/addons use plan: 'foo' instead of plan: {name: 'foo'} (matches AddOnCreateOpts canonical shape).
• addons:rename PATCH body now includes plan (required by the schema; we forward the addon's current plan unchanged).
• addons:detach mocks return JSON bodies for the DELETE response (the SDK's dispatcher parses, where the legacy client tolerated empty).
• data:pg:migrate createAddonStub.args[0][N] indexes shifted down by 1 (no more heroku first arg).
• addons:wait test replaces lolex with sinon's useFakeTimers({toFake: ['Date'], shouldAdvanceTime: true}) so the SDK's real setTimeout polling drives the test while Date.now() can still be fake-ticked for the >5s notifier threshold.
• pipelines:promote test stubs Cmd.promotePipeline (a static reference to the standalone SDK function), with the callback signature shifted to 3-arg (_ctx, _body, options) and firstCall.args[1] for body assertions.
• addons and addons:info tests split the nock scope so apiSdk (Accept-Expansion required) wraps only the resolve POSTs, while api (no reqheader constraint) wraps the global /addons and the /addons/<id>/addon-attachments calls — matching the SDK's per-call header scoping.

Pinned to @heroku/sdk branch eb/feat/addon-create-and-wait (PR heroku/heroku-sdk#27). Once that merges, the pin flips back to main.

Type of Change

• refactor: Refactoring existing code without changing behavior

Testing

Run the touched-area unit tests:

npx mocha 'test/unit/commands/addons/*.unit.test.ts' \
          'test/unit/commands/maintenance/*.unit.test.ts' \
          'test/unit/commands/pipelines/*.unit.test.ts' \
          'test/unit/commands/data/pg/{create,fork,migrate}.unit.test.ts' \
          --timeout 120000

Expect 211 passing, 0 failing.

End-to-end smoke (against heroku-dev-tools team or any team you have access to):

npm run build
./bin/run addons --json                                # global list (no expansion)
heroku apps:create eb-addons-test --team heroku-dev-tools
./bin/run addons:create heroku-redis:mini -a eb-addons-test --wait
                                                       # exercises createAndWait + onProvisioning
                                                       # expect price line, provision message,
                                                       # 'Waiting for ...', 'Creating <name>... done'
./bin/run addons -a eb-addons-test                     # app-scoped list (with expansion)
./bin/run addons:info <returned-addon-name>            # exercises describe + grandfathered pricing
./bin/run addons:services
./bin/run addons:plans heroku-redis                    # exercises listPlans + native sort
./bin/run addons:upgrade <addon-name> premium-0        # bare plan auto-qualifies via SDK
./bin/run addons:rename <addon-name> renamed-redis     # exercises info + update + plan forward
heroku addons:attach renamed-redis --as REDIS_BACKUP -a eb-addons-test
./bin/run addons:detach REDIS_BACKUP -a eb-addons-test # exercises infoByApp + delete + release.list
./bin/run maintenance:on -a eb-addons-test
./bin/run maintenance -a eb-addons-test                # expect "on"
./bin/run maintenance:off -a eb-addons-test
heroku apps:destroy eb-addons-test --confirm eb-addons-test

For the confirmation-required path, repeat addons:create against an app whose owner team requires confirmation; expect the CLI to prompt for the team name, then succeed.

Related Issues

GUS work item: W-22265114

[tlowrimore-heroku]

Couple of things; no show-stoppers:

• Curious to know why the different patterns for getting a reference to the SDK platform service. I see some cases where createPlatformClient is used and other cases where const {platform} = new HerokuSDK() is used.
• Not sure if you were on the pointing session where we discussed doing away with using nock in favor of mocking the SDK. I realize now that I update the CLI apps update WI to mention this, but I missed the card for this work, so no big deal.

Otherwise, nice job!

[eablack]

Thanks for the review!

Curious to know why the different patterns for getting a reference to the SDK platform service.

Good catch — the inconsistency was inherited from working through the migration in stages. Standardized on new HerokuSDK({extensions: [...]}).platform everywhere in 41f1bc7. For files that don't need extension methods, it's constructed with no extensions, which gives the same surface as createPlatformClient but keeps the construction shape uniform.

Not sure if you were on the pointing session where we discussed doing away with using nock in favor of mocking the SDK.

Yeah I was — for new tests we agreed to stub the SDK directly. The reason this PR still leans on nock so much is that I was adjusting existing nock-based tests rather than rewriting them, since updating in place was usually a smaller surgery than restructuring the whole fixture. Going forward I'll do net-new tests in the SDK-stub style.