refactor: use @heroku/sdk for pg:backups commands (part 2)

[erika-wallace]

Summary

This PR updates three pg:backups commands — pg:backups:schedule, pg:backups:schedules, and pg:backups:unschedule — to use the SDK instead of calling the Heroku API directly.

Changes Made

• pg:backups:schedule now loads the database with data.database.describe and creates the schedule with data.transferSchedule.create. The command no longer builds schedule_name; the SDK sets it from the resolved attachment name.
• pg:backups:schedules now lists schedules with data.transferSchedule.list.
• pg:backups:unschedule now lists schedules with data.transferSchedule.list and deletes the match with data.transferSchedule.delete.
• src/lib/pg/types.ts no longer defines TransferSchedule or PublicUrlResponse. Those types now come from @heroku/sdk and @heroku/types.
• src/commands/pg/backups/index.ts drops an unused transferExtensions import left over from the pg:backups part-1 migration (refactor: use @heroku/sdk for pg:backups commands (part 1) #3958).

Behavior notes (also documented in V12-CHANGES.md):

• pg:backups:schedule's "not yet provisioned" error now names the DATABASE argument (or DATABASE_URL when omitted) instead of the resolved add-on's resource name, since the SDK's NotFoundError surfaces before the add-on name is known. The scheduling spinner still shows that add-on name when database.describe returns name; if name is absent it falls back to the DATABASE argument, then DATABASE_URL.
• pg:backups:unschedule's "no daily backups found" error now names the DATABASE argument (or the auto-selected schedule name) instead of the resolved add-on's resource name.

Type of Change

Breaking Changes (major semver update)

• Add a ! after your change type to denote a change that breaks current behavior

Feature Additions (minor semver update)

• feat: Introduces a new feature to the codebase

Patch Updates (patch semver update)

• fix: Bug fix
• deps: Dependency upgrade
• revert: Revert a previous commit
• chore: Change that does not affect production code
• refactor: Refactoring existing code without changing behavior
• test: Add/update/remove tests

Testing

Notes:

Requires an app with a Heroku Postgres legacy-tier database attached.

Setup:

1. Pull down this branch
2. npm i && npm run build
3. heroku logout && HEROKU_NETRC_WRITE=true ./bin/run login

Steps:

1. Schedule the default database. Verify Scheduling automatic daily backups of <name> at 4:00 UTC... done.

./bin/run pg:backups:schedule --app <app> --at '4:00 UTC'

2. Schedule a named database. Verify Scheduling automatic daily backups of <name> at 14:00 America/Los_Angeles... done. If <database> only has one attachment, this replaces the step 1 schedule instead of adding a second one.

./bin/run pg:backups:schedule <database> --app <app> --at '14:00 America/Los_Angeles'

3. List schedules. With one attachment, verify a single DATABASE_URL: daily at 14:00 America/Los_Angeles line and no 4:00 UTC line. With a different attachment, both new schedules are listed. Other schedules already on the app are listed too.

./bin/run pg:backups:schedules --app <app>

4. Unschedule one schedule by name. Verify Unscheduling <schedule-name> daily backups... done.

./bin/run pg:backups:unschedule <schedule-name> --app <app>

5. Unschedule with no argument. This removes the only remaining schedule and prints Unscheduling <name> daily backups... done. If more than one schedule is still on the app, the command errors and lists them instead. If none remain, it errors with No schedules on <app>.

./bin/run pg:backups:unschedule --app <app>

6. List schedules. The schedules from steps 1 and 2 are gone. If nothing else was scheduled, verify No backup schedules found on <app>. Otherwise the remaining schedules are listed.

./bin/run pg:backups:schedules --app <app>

Cleanup:

• ./bin/run logout

Screenshots (if applicable)

Related Issues

GUS work item: W-23386457

[tlowrimore-heroku]

LGTM!