feat(payments): discount engine (phase 1 — discount codes)

[v0l]

Fixes #57 (phase 1 — discount codes; phase 2 is automatic code-less discounts, stacking and the admin condition builder).

A discount's eligibility and its effect are one CEL expression returning a decision map, so tiered and threshold offers need no new column each time a campaign shape changes:

{'percent': 10}
order.amount >= 5000 ? {'percent': 10} : {}
order.intervals >= 12 ? {'percent': 15} : order.intervals >= 6 ? {'percent': 10} : {}
order.amount >= 10000 ? {'amount': 500, 'currency': 'EUR'} : {}

Only the integrity guards are columns — validity window, total usage limit, per-user limit — because they need atomic enforcement at redemption and cannot be counted inside a side-effect-free expression.

⚠️ CEL map keys must be quoted. The examples in the issue ({percent: 10}) are protobuf syntax; in CEL a bare identifier in a map literal is a variable reference and fails with Undeclared reference to 'percent'. The admin condition builder must emit quoted keys.

Safety

Whatever the rule returns is clamped in Rust: percent to 0..=100, a fixed amount to >= 0, and the total to at most the order amount. A non-decision return type (a bare 10, a string) is rejected rather than guessed at — treating it as "10 percent" would let a typo change what customers are charged. A rule that cannot be evaluated applies no discount instead of failing the customer's payment. Rules see only a hand-built context (order, user, history, now), never a database row: that is the security boundary, and fields are added to it deliberately.

Applying a discount

• To the order, not a line item. An order aggregates line items plus setup fees, so discounting one cost quote would miss part of the bill.
• Before tax and fees. Each line's VAT is recomputed from the amount actually charged — a customer is never taxed on money they do not pay.
• Priced fresh. A code entered after an invoice already existed used to hand back the full-price pending invoice while reporting success (caught by the e2e run — see below).
• Limits consumed at settlement, not at invoice creation, so an abandoned invoice burns no stock and does not lock a customer out of a one-per-customer offer. Settlement lives in apply_payment, which every payment method reaches (including the admin override via WorkJob::ApplySubscriptionPayment), and is idempotent under replayed webhooks. used_count is incremented unconditionally: a customer who has paid a discounted invoice must be honoured, so the count records what really happened and then refuses every later quote.
• One discount per payment, enforced by UNIQUE (subscription_payment_id) on the redemption row — the no-stacking rule in a place it cannot be bypassed.
• Referral needs no change: commission is computed from the recorded payment amount, which is already net of the discount.

Data model note

Provenance lives on discount_redemption (settled / created / settled_at + the unique payment key) rather than as columns on subscription_payment. The payment's amount is already net of the discount, so tax, refunds and referral are correct without them, amount_off is recorded exactly once, and the unique key is what makes settlement idempotent.

API

Admin (discount RBAC resource, granted to super_admin by migration — a resource with no grants is unreachable): /api/admin/v1/discounts CRUD, {id}/redemptions, and POST /api/admin/v1/discounts/preview, which evaluates a rule against a sample order without saving. The preview is what makes raw-CEL advanced mode safe: it reports the clamped decision ({'percent': 900} shows percent: 100) and the reason for a failure.

Customer: code on GET /api/v1/vm/{id}/renew and GET /api/v1/subscriptions/{id}/renew, with a discount line on the payment response. An unusable code fails the request rather than quietly invoicing full price — the customer typed something and is owed an answer — with one generic message for every rejection so the endpoint cannot enumerate valid codes.

Two bugs the e2e run found (both fixed here)

1. A code was answered with the existing full-price invoice. Pending payments are reused when method/type/time_value match, so entering a code after an invoice existed returned the un-discounted one. Fixed with get_vm_cost_for_intervals_fresh, used whenever a code is supplied.
2. Lifecycle cleanup could not delete the company — discount has a real FK to company.

Separately, and not fixed here: pending-payment reuse matches on (method, type, time_value) and not on price, so an unpaid invoice created before a VM upgrade is reused after it, billing the old rate. Pre-existing and worth its own issue.

Testing

• ~70 unit tests across the rule evaluator, clamping, engine, DB layer and the renewal/settlement path. 100% function coverage on the new discount module (one closure short in engine.rs).
• 6 new e2e tests in lnvps_e2e/src/discounts.rs plus a customer-path block in the lifecycle test (code reduces the invoice, unpaid invoice consumes nothing, settlement redeems once, per-user limit then refuses, redeemed discount cannot be deleted but can be deactivated). Full e2e suite: 185 passed, 0 failed.
• Both migrations applied to a scratch DB on top of the full migration history against MariaDB, with each statement in the MySQL impl run by hand there.

Design record: work/discount-engine.md. Rule-authoring guide: docs/agents/discounts.md.

[v0l]

Rebased onto master (picks up the VM-placement and Proxmox local-storage fixes; one changelog conflict, both entries kept), and pushed a second commit widening the rule context.

order.template_id + order.product → order.items. The old pair could express "this plan" and nothing else: a multi-line order reported no template at all, a custom build was indistinguishable from an unknown one, and every new product shape would have needed another scalar bolted onto the context. A rule now sees each line of the order, typed by the product it bills for and carrying that product's own properties:

order.items.exists(i, i.type == 'vm' && i.template_id == 3) ? {'percent': 10} : {}
order.items.all(i, i.type == 'vm' && i.cpu >= 8) ? {'percent': 5} : {}
order.items.exists(i, i.type == 'vm' && i.template_id == null) ? {'percent': 10} : {}   # custom builds
order.items.exists(i, i.type == 'ip_range') ? {'percent': 15} : {}

type	Fields
vm	vm_id, template_id (null = custom build), region_id, cpu, memory, disk_size, disk_type, ip4_count, ip6_count
app	deployment_id, app_id, cluster_id, resource_multiplier
ip_range	subscription_id, cidr
asn_sponsoring	subscription_id, asn, registry
dns_hosting	—
marketplace_node_fee	node_id

Two decisions worth review:

• Type is certain, detail is best-effort. The line item says what it bills for, so i.type is always right, but the product row behind it may not exist yet — an IP range or sponsored ASN is allocated when the first payment settles, so on a purchase order there is nothing to read. Those fields are null and the line is still reported; dropping it would make i.type == 'ip_range' silently false on the very order buying one. Comparing against a null detail fails the rule, which applies no discount, so "unknown" never costs money.
• Items carry no price. A VPS line's stored amount is not what the VM costs — VMs are priced by the pricing engine from their cost plan in the payment currency, while the stored amount is in the subscription's base currency and is not maintained for VPS lines. A per-item figure would be wrong exactly where a rule leaned on it. order.amount remains the order total.

The admin preview accepts items, so a rule can be tried against a custom build, a multi-line order or a non-VM product before it is saved.

Rechecked on the new base: workspace unit tests green, clippy clean, 100% function coverage on all five discount files, and the full e2e suite still passes (185).