fix(billing): resume a pending top-up as a top-up, not a subscription (#14715)

## Description

Billing status can return an in-flight billing operation
(`pending_billing_op_id` + `action_url`) so a client that lost its local
reference can resume the payment — a reload, a cleared browser, a
different device. The recovery path in `useWorkspaceBilling` assumed
that operation was always a subscription and passed a hardcoded
`'subscription'`.

That assumption is a latent bug regardless of what the server sends
today: any non-subscription operation surfaced there takes the wrong
branch throughout.

- `isSettingUp` turns true, so `SubscriptionPanelContentWorkspace`
replaces the whole panel with a "setting up your subscription" spinner —
hiding the user's actual plan for as long as the operation is pending
- `topupActionOperation` requires `type === 'topup'`, so the top-up
dialog's own recovery prompt never matches
- `handleSuccess` runs `reconcileSubscriptionSuccess()` instead of
`fetchStatus()` + `fetchBalance()`, so credits just purchased never
appear
- the toast and telemetry describe a subscription checkout

Uses the operation type when the API reports one, falling back to
`'subscription'` when it does not — so this is inert against a server
that never sends the field, and correct the moment one does.

**Status:** the server side does not populate a top-up here yet. This is
the client half, landing first because it is safe in isolation; without
it, a server that starts reporting top-ups would drive the wrong UI.
Treat it as removing a hardcoded assumption, not as shipping a
user-visible fix on its own.

## Checklist

- [x] Test added — `recovers a pending top-up as a top-up, not a
subscription`, confirmed to fail without the fix
- [x] `pnpm test:unit` (72 passed in the touched suite), `pnpm
typecheck`, `pnpm lint`, `pnpm format`

## Follow-up (not in this PR)

`billingOperationStore` gives a top-up 120s to discover an
authentication URL (`TIMEOUT_MS`) while a subscription gets 5min
(`SUBSCRIPTION_ACTION_DISCOVERY_TIMEOUT_MS`). Only bites when the
payment page is slow to appear, so it is kept separate.

Author: wei-hai

src/platform/workspace/api/workspaceApi.ts

@@ -294,6 +294,7 @@ export interface BillingStatusResponse {
   change_at?: string
   billing_status?: BillingStatus
   pending_billing_op_id?: string
+  pending_billing_op_type?: 'subscription' | 'topup'
   action_url?: string
   has_funds: boolean
   cancel_at?: string

src/platform/workspace/composables/useWorkspaceBilling.test.ts

@@ -291,6 +291,27 @@ describe('useWorkspaceBilling', () => {
       )
     })
 
+    it('recovers a pending top-up as a top-up, not a subscription', async () => {
+      const actionUrl = 'https://invoice.stripe.com/sensitive-token'
+      mockWorkspaceApi.getBillingStatus.mockResolvedValue({
+        ...activeStatus,
+        billing_status: 'pending_payment',
+        pending_billing_op_id: 'op-topup',
+        pending_billing_op_type: 'topup',
+        action_url: actionUrl
+      } satisfies BillingStatusResponse)
+
+      const billing = setupBilling()
+      await billing.fetchStatus()
+
+      expect(mockStartOperation).toHaveBeenCalledWith(
+        'op-topup',
+        'topup',
+        undefined,
+        actionUrl
+      )
+    })
+
     it('does not restart an operation recovered by an earlier status read', async () => {
       mockWorkspaceApi.getBillingStatus.mockResolvedValue({
         ...activeStatus,

src/platform/workspace/composables/useWorkspaceBilling.ts

@@ -210,7 +210,7 @@ export function useWorkspaceBilling(): BillingState & BillingActions {
       ) {
         void billingOperationStore.startOperation(
           status.pending_billing_op_id,
-          'subscription',
+          status.pending_billing_op_type === 'topup' ? 'topup' : 'subscription',
           undefined,
           status.action_url
         )