Billing endpoints trust arbitrary user_id

Problem

Billing endpoints accept caller-supplied user identifiers without verifying that the caller owns those identifiers.

Observed behavior:

• /billing/balance?user_id=... reads balance data for the requested UUID.
• /billing/usage?user_id=... reads usage data for the requested UUID.
• /billing/checkout accepts body user_id.

Risk

A caller may be able to read another user's billing state or initiate checkout flows tied to arbitrary user IDs.

Expected behavior

Billing endpoints should derive the user from verified authentication and should not trust query/body user_id as identity proof.

Acceptance criteria

• Billing endpoints require authentication.
• Balance, usage, and checkout use the authenticated user's ID from verified claims.
• Caller-supplied user_id is removed or treated only as an admin-only parameter behind explicit authorization.
• Regression tests cover unauthenticated requests, wrong-user spoofing attempts, and valid authenticated requests.

Start by locating the handlers for /billing/balance, /billing/usage, and /billing/checkout, then trace the existing authentication and claim-validation entry points. Add regression coverage for unauthenticated requests, wrong-user spoofing, and valid authenticated requests; done means all three endpoints use the authenticated user's ID rather than an untrusted caller-supplied value.