billing: project legacy Stripe reactivation through server capabilities

## Problem / Goal

PR #15967 must fall back to client-derived subscription lifecycle policy because the server capabilities response does not project `can_reactivate` for `legacy_stripe` workspaces. That leaves frontend policy deciding when the server answer applies and risks the compatibility fallback becoming permanent.

The server capability should be authoritative for legacy-rail reactivation.

## Proposed Solution

- Coordinate the backend capability projection for `legacy_stripe` workspaces.
- Return the correct `can_reactivate` value from the capabilities endpoint.
- Once deployed, remove the frontend membership fallback and consume the generated capability directly.

## Acceptance Criteria

- The capabilities endpoint returns authoritative reactivation state for `legacy_stripe` workspaces.
- Frontend policy no longer branches to membership-derived reactivation permission.
- Generated contracts and focused frontend/backend tests cover legacy and workspace billing rails.
- Rollout order preserves compatibility while backend and frontend changes deploy.

Follow-up from the explicitly non-blocking review thread on #15967:
https://github.com/Comfy-Org/ComfyUI_frontend/pull/15967#discussion_r3862053299