feat(payments): source payment providers from database, drop YAML config

[v0l]

Fixes #182.

Completes the PaymentMethodFactory integration so payment providers come from the database instead of YAML, and removes the now-redundant YAML config entirely (per discussion, the DB is the single source of truth).

What changed

• Startup wiring (bin/api.rs) — the Lightning node, on-chain provider and Revolut service are built from the per-company payment_method_config rows via PaymentMethodFactory (default/first company). Startup fails with a clear error if no company exists or no enabled Lightning/on-chain config is present.
• On-chain config fields respected — min_confirmations, address_type and account from OnChainProviderConfig now take effect (previously hardcoded to 1 / p2wkh / default account in the old Settings::get_onchain()).
• Settlement listeners — Revolut/Stripe config loading routed through the factory for consistency.
• YAML removed — deleted Settings.lightning / Settings.revolut, the LightningConfig enum, Settings::get_node/get_onchain/get_revolut, and the one-time YAML→DB seed migration. config.yaml updated.
• SubscriptionHandler::new now takes the Revolut service as a parameter (was derived from settings.get_revolut()); all call sites updated.

Multi-company semantics

The runtime still resolves a single global provider set from the default (first) company. True per-company provider routing is left as documented future work — the data model already carries company_id end to end, but the settlement handlers and SubscriptionHandler resolve one provider set per process.

⚠️ Operator note (breaking)

There is no YAML→DB bootstrap anymore. A deployment must have seeded payment_method_config rows before upgrading (anything that ran the previous seed migration already has them). New deployments configure providers via POST/PATCH /api/admin/v1/payment_method_configs; the API refuses to start without an enabled Lightning + on-chain config for the default company.

Testing

• lnvps_api lib test suite: 221 passed, 0 failed (3 ignored).
• lnvps_api / lnvps_api_common / lnvps_db build clean (lib + tests), no new warnings/clippy lints.
• Net −294 lines.

No API surface change.

[v0l]

Follow-up: fixed the E2E harness, which broke because the user API now requires DB-configured payment providers (no YAML fallback).

scripts/run-e2e.sh now:

• starts the admin API first (it runs the schema migrations and needs no payment providers),
• seeds payment_method_config rows (LND Lightning + OnChain) pointing at the docker-compose LND node, via mysql_exec (idempotent),
• then starts the user API, which now finds the config and boots.

Also dropped the now-ignored lightning: section from .github/e2e/api-config.yaml. Verified the seeded config JSON round-trips into ProviderConfig (lnd / onchain).

[v0l]

✅ Ran the full E2E suite locally against the docker-compose stack: 123 passed, 0 failed.

Sequence confirmed working:

• Admin API ready after 4s (now runs migrations — see below)
• === Seeding payment_method_config (LND Lightning + OnChain) === (no error)
• User API ready after 10s (boots from the DB-seeded providers)
• Payment lifecycle tests (test_full_lifecycle, test_admin_complete_vm_payment_lifecycle, …) all green — so the seeded LND Lightning config is genuinely exercised.

One extra fix was needed: admin_api.rs never actually called db.migrate() (despite its "Connect database and migrate" comment) — it relied on the user API migrating first. Since the harness now starts the admin API first to create the schema before seeding, I added the missing db.migrate().await?. This is also a correctness improvement in its own right (the admin API no longer assumes another process migrated the DB).