feat(marketplace): one-off node listing fee, and stop one-offs expiring

[v0l]

Operators register hardware for free and have it reviewed for free, but an admin cannot approve a node until its listing fee is paid. Per node, so paying once does not license a fleet. Non-refundable, so LNVPS never custodies operator money and needs no return or slashing procedure.

Why the fee is a subscription, not a new payments table

subscription_payment is the only table the Lightning settlement listener resolves against (invoice.rs → get_subscription_payment), and its resume cursor is last_paid_subscription_invoice. A parallel marketplace_bond table would have had to extend both — and a paid fee that missed either would settle into a not found log line and be lost.

The problem that modelling it as a subscription created

There is no path through subscription_payment_paid that leaves expires NULL — both branches set it. So a paid one-off would acquire an expiry, and check_subscriptions would start mailing the operator "your subscription will expire soon" about something they bought outright.

One-offs are now recognised from the data rather than a flag: a subscription that bills nothing recurring but carries a setup fee has nothing to renew, so expires stays NULL — which every expiry query already filters on with expires IS NOT NULL.

The narrowness is the point. The rule requires a setup fee and no recurring amount. Checking only "no recurring amount" would have swept in free and fully-discounted subscriptions, which have neither — and a zero-amount VM that stopped expiring would never be cleaned up.

Verified against MariaDB across all three shapes:

Subscription	SUM(amount)	SUM(setup_amount)	one-off?
Node listing fee	0	5000	yes
Paid VPS	1000	0	no
Free VPS	0	0	no — must still lapse

There was a second trap in the same statement: the expiry UPDATE is also what sets is_active and is_setup. Skipping it wholesale would have left a paid fee looking unpaid, so the one-off branch sets them explicitly.

Schema

uk_marketplace_node_line_item makes one paid fee cover exactly one node — without it two nodes could point at the same payment and the per-node gate would silently degrade into the per-operator model that was rejected. Confirmed against MariaDB: sharing a fee gives 1062, a dangling line item gives 1452.

The mock enforces the unique key and the FK, so tests about them are not fiction.

Endpoint

POST /api/v1/marketplace/nodes/{id}/fee { region_id }, paid through the normal subscription renewal endpoint.

The region is a parameter because a subscription needs a company_id, and every other product derives one from the thing being bought (IP range → IP space, VM → host region). A node that has just registered belongs to no region, so there is nothing to derive it from. Naming the target region supplies the company and currency, and tells the reviewing admin where the hardware is meant to live.

Mutation testing

Every run included a control on unmutated code:

Guard disabled	Result
Give one-off fees an expiry (the dunning regression)	caught
Treat free subscriptions as one-off	caught
Leave a paid one-off inactive	caught
Share one fee between two nodes (insert)	caught
Share one fee between two nodes (update)	caught
Create a second fee subscription per node	caught
Invoice a zero fee that can never be paid	caught
Bill the fee as recurring	caught
Never link the fee to the node it paid for	caught

The fee handler provisions nothing — paying makes a node approvable, an admin still approves it — and its expiry callbacks bail! rather than no-op, because reaching them means the one-off invariant broke, and quietly deactivating a node whose operator paid in full is the worst available outcome.

No new clippy warnings (281 before and after).

Next (3b): admin approve/reject/suspend/drain, with approval gated on this fee and on a pinned certificate.