Migrate bin/deployments/index.ts to the typed openapi-fetch client

[andykenward]

Background

In #784 the action's Cloudflare REST calls moved to a typed openapi-fetch client (src/common/cloudflare/api/client.ts), with the {success, result, errors} envelope unwrapped by unwrap/unwrapSuccess in src/common/cloudflare/api/fetch-result.ts.

The deployments:delete dev utility (bin/deployments/index.ts) was left out of that migration. It still:

• hand-builds the API URL (/client/v4/accounts/${...}/pages/projects/${...}/deployments) and the ?force=true delete URL,
• sets the Authorization / Content-Type headers manually,
• casts raw fetch(...).json() to FetchResult<Array<PagesDeployment>> / FetchResult<null> (the same drift-prone assertion the rest of the codebase no longer does).

Task

• Migrate bin/deployments/index.ts to cloudflareClient.GET/DELETE + unwrap/unwrapSuccess, so its request paths, params, and response types are inferred from the generated schema.
  • Note: this script runs standalone (node bin/deployments/index.ts, no @actions/core context) — confirm useCommonInputs()-based auth in the client middleware works here, or parameterize the token, since this path reads CLOUDFLARE_API_TOKEN directly from process.env.
• Once migrated, drop the now-unused FetchResult import here and re-check whether FetchResult is still needed elsewhere (it's also used by fetch-error.ts).
• Minor cleanup: remove the stale commented-out MOCK_API_PATH reference in __tests__/deploy/main.test.ts:38 (the symbol was renamed to MOCK_API_PATH_PROJECT).

Why it's deferred

bin/deployments/index.ts is a maintainer-only utility, not part of the bundled action, so it was out of scope for #784. Consistency-only, no behavior change expected.