feat: refactor pg commands to leverage sdk

[michaelmalave]

Summary

This branch migrates core CLI command surfaces to @heroku/sdk and adds tooling to accelerate further command migrations, with broad updates across addons, pipelines, maintenance, Postgres, logs, and supporting libraries. Scope includes command implementations, shared helpers, and corresponding unit test updates to align with SDK request/response behavior.

• Integrate @heroku/sdk into the CLI and command runtime paths
• Migrate addons, pipelines, maintenance, Postgres, and logs commands from legacy API client patterns to SDK APIs
• Refactor shared helpers and command internals to use SDK-compatible data flows
• Add SDK migration codemod/tooling and documentation for follow-on command migrations
• Remove obsolete legacy PG upgrade types no longer needed after SDK migration
• Update unit tests across migrated commands and libraries to validate new SDK-backed behavior

Type of Change

• fix: Bug fix or issue (patch semvar update)
• feat: Introduces a new feature to the codebase (minor semvar update)
• perf: Performance improvement
• docs: Documentation only changes
• tests: Adding missing tests or correcting existing tests
• chore: Code cleanup tasks, dependency updates, or other changes

Verification

npm ci
npm run lint
npm test

Additional Context

• Breaking: none expected; behavior is intended to remain equivalent while switching API client internals
• Risk: medium; wide command-surface migration, mitigated by broad unit test updates
• Follow-up: continue migrating remaining commands with the new codemod/tooling path and monitor edge-case API error mapping

Related Issue

W-22265695

[tlowrimore-heroku]

LGTM!

Comments:

• I see you're having to do a lot of double assertions (i.e. x as unknown as Y), in this PR. I think You, Eric, and I should discuss how best to avoid this. I think the crux of the issue is that SDK returns types defined by @heroku/types, but we're still opting to use the types defined in the CLI.
• I also see several updates to nock. There was a discussion a couple of weeks ago--I think you may have been OOO--where there was a strong consensus to mock the SDK, rather than mocking the HTTP request/responses. We should probably revisit this conversation to see if everyone still feels this is the best approach.

[tlowrimore-heroku]

Nice! I like the sdk-adapter approach!