The current endpoint (/marketplace/billing/charges/has-funds) only returns a boolean for whether a wallet has any funds — it doesn't check against a specific charge amount. This breaks pre-flight cost checks for marketplace apps that incur variable, usage-based costs before billing the end user.

For example, our app enriches contacts with email and phone data. If a user requests enrichment for 50 contacts, we incur a cost from our enrichment provider for every successful (positive) result — we only know the actual charge amount after the API call completes, since we're billed per successful retrieval, not per request. That means we can't charge the exact final cost to the wallet ahead of time. What we can do is calculate the maximum possible charge upfront (e.g. 50 contacts × per-contact rate, assuming a 100% success rate) and confirm the wallet can cover that worst-case amount before running the job — otherwise we risk incurring costs we can't recover from the end user.

Requested change:

Add a cost (or amount) query parameter to the endpoint so it checks whether the wallet balance can cover that specific charge, e.g.:

GET /marketplace/billing/charges/has-funds?cost=6.35

Response: same boolean as today (true/false), but evaluated against the given cost rather than just checking for a non-zero balance.

This lets apps pass in a worst-case/estimated cost and confirm funds are sufficient before incurring their own upstream costs on batch operations.