feat(apps): per-deployment resource multiplier for upgrades

[v0l]

Managed app deployments were fixed at the catalog app's footprint and price, so the only way to offer a customer a bigger instance was to publish a second catalog entry. This adds a per-deployment resource_multiplier — the deployment's size as an integer multiple of the base app, applied to resources and price together.

What changed

Layer	Change
Schema	app_deployment.resource_multiplier INTEGER UNSIGNED NOT NULL DEFAULT 1 — existing deployments are base size, no backfill
Operator	Container CPU/memory limits, PVC sizes and the namespace storage quota scale by the multiplier
Capacity	A deployment occupies footprint × multiplier
Pricing	calculate_app_upgrade_cost — prorated, mirroring VM upgrades
Billing	Resize applied on payment settlement; line item repriced to app.amount × multiplier
API	POST /app-deployments/{id}/upgrade-quote and /upgrade

Design notes

Increase-only is a constraint, not a policy. A PersistentVolumeClaim cannot shrink, so a downgrade would strand storage. It's enforced in three places — the API guard, the pricing engine, and again at settlement — so a replayed or out-of-order payment can never shrink a deployment.

The resize happens only when the payment settles. An abandoned upgrade leaves the deployment untouched. Quoting never mutates anything (there's an e2e assertion for exactly this).

A multiplier of 1 returns quantities untouched, so existing deployments render byte-identical pod specs and don't churn when this rolls out. Legacy rows decoding as 0 clamp to base size.

Capacity counts the multiplied footprint. Counting the base footprint would let upgraded deployments silently oversubscribe a cluster. The upgrade's additional footprint must fit on the cluster the deployment already runs on — it can't be moved, because its volumes are there.

Refactor: price_to_payment_with_type was VM-bound (it took a vm_id and looked up the VM just for user_id and a description). Split out price_to_payment_for_subscription, which needs only a subscription, a user and a description. The VM path delegates to it with identical description strings, so VM behaviour is unchanged.

⚠️ Operator prerequisite

Growing a PVC requires a StorageClass with allowVolumeExpansion: true. Without it the pod specs scale but the volumes do not, and the deployment reports a failed expansion. There is no preflight check for this yet.

Tests

New coverage: operator scaling (including the 1× / 0× / unparseable passthrough cases), capacity accounting with mixed multipliers, prorated quote math, upgrade rejection cases (downgrade, no-op, expired subscription), and settlement (applies + reprices, never shrinks, tolerates bad metadata). Plus e2e assertions on the new endpoints.

Crate	Result
lnvps_api	276 ✅
lnvps_api_common	265 ✅
lnvps_db	44 ✅
lnvps_api_admin	31 ✅
lnvps_operator	27 ✅

Known gaps

• validate_app_upgrade, create_app_upgrade_payment and the two handlers have no unit tests — they need a full RouterState, which apps.rs has no harness for. They are covered by e2e, which cargo llvm-cov won't count, so function coverage for apps.rs will show a gap.
• resource_multiplier is read-only in the admin API by design: setting it without a payment would desync the billed price from the provisioned size. No admin override for support cases yet.