Confirm cancel_at parity with the legacy end_date field for legacy_stripe workspaces

Residual from the review of #14614. Non-blocking, needs a backend answer rather than code.

#14614 repointed Cloud subscription status from `/customers/cloud-subscription-status` to the canonical `/api/billing/status`, which changes the cancellation predicate from `end_date` to `cancel_at`:

```ts
// src/platform/cloud/subscription/composables/useSubscription.ts
return !!subscriptionStatus.value?.cancel_at
```

Everything in this repo says the two are the same scheduled-end concept, and I do expect this is correct:

- the registry schema documents `end_date` as "the date when the subscription is set to end"
- `packages/ingest-types/src/types.gen.ts` documents `cancel_at` as "when the subscription will become inactive (if canceled)"
- `browser_tests/tests/billingFacadeConsumers.spec.ts` on main already maps `cancel_at: s.end_date ?? undefined` under a comment saying the two shapes mirror each other

What is not pinned by anything is the backend behaviour: does `GET /api/billing/status` populate `cancel_at` for a `legacy_stripe` personal workspace in every state where `/customers/cloud-subscription-status` populated `end_date`?

If it leaves it unset in some cancellation state, `isCancelled` silently reports false for that cohort. The regression test added in #14614 (`useSubscription.test.ts`) supplies `cancel_at` by construction, so it would still pass.

One confirmation from the billing owner closes this. No code change either way if the answer is yes.

Thread: https://github.com/Comfy-Org/ComfyUI_frontend/pull/14614#discussion_r3708210992