feat: governance execution verification, quadratic voting, oracle registry, insurance pool integration

[Asta-wizard]

Closes #529
Closes #530
Closes #531
Closes #532

What changed

#531 — Proposal execution verification

• execute_proposal fired invoke_contract for the cross-contract action call and unconditionally marked the proposal Executed, even if the callee panicked or returned an error.
• Switched to try_invoke_contract so the outcome is observable. On failure the proposal is left at Passed (timelock/eta untouched) instead of advancing to Executed, a ProposalExecutionFailed event is emitted, and execute_proposal returns a new ExecutionFailed error. Since the proposal stays Passed with its timelock already expired, calling execute_proposal again simply retries the same action.
• Also fixes tests_benchmarks::setup_benchmark_env(), which called initialize() with the pre-Implement on-chain mechanism to update distribution reward formulas #544 3-argument signature and hadn't compiled since the distribution_contract parameter was added — this was blocking the entire iln_governance test binary from building.

#530 — Quadratic voting

• Linear vote weighting (weight = balance + delegated) lets a holder with 100x the tokens of another get exactly 100x the voting influence.
• Added a governance-controlled toggle (set_quadratic_voting_enabled / is_quadratic_voting_enabled, default off) that switches cast_vote to weight = isqrt(balance + delegated) — a whale with 100x the tokens ends up with only 10x the influence. isqrt is a floor integer square root via bounded binary search (no floating point in a #![no_std] contract).
• The weight actually applied to each vote is now recorded (AppliedVoteWeight, same TTL as HasVoted) and readable via get_applied_vote_weight.
• Default-off keeps existing/in-flight proposals on the linear model they were built against. Design tradeoffs are written up in docs/adr/ADR-009-quadratic-voting.md.

#532 — Governance-controlled oracle registry

• Config.price_oracle was a single address used only for payer identity verification. Added an OracleFeedType registry (Price/Identity/Credit) resolved per-token-override → feed-type-default → (Identity only) the legacy price_oracle field, so existing set_price_oracle-only configs keep working unmodified.
• fund_invoice now resolves through the registry for the Identity feed, keyed by the invoice's token.
• Wired governance proposal actions (RegisterOracle, RemoveOracle) so the registry is actually governance-controlled via execute_proposal.
• Health monitoring needed a dedicated entrypoint (check_oracle_health) rather than piggybacking on fund_invoice, since Soroban rolls back all storage writes for an invocation that returns Err — a health snapshot written just before fund_invoice's existing OracleDataStale rejection would never persist. Design tradeoffs are written up in docs/adr/ADR-010-oracle-registry.md.

#529 — Insurance pool integration

• insurance_pool's own interface docs already described this follow-up: "the main invoice_liquidity contract, which (in a follow-up) invokes claim from its default-handling path via the generated InsurancePoolClient."
• Added insurance_pool as a regular (not just dev) dependency so claim_default can use the generated InsurancePoolInterfaceClient directly. Deployed pool address is a new admin-gated DataKey::InsurancePool (set_insurance_pool/get_insurance_pool).
• After the existing principal-refund loop in claim_default, checks whether the claiming LP is enrolled and, if so, attempts pool.claim(invoice_id, lp). The pool credits the LP directly from its own balance — invoice_liquidity never holds or forwards the payout.
• Uses try_is_enrolled/try_claim (not the panicking variants) so a paused, empty, or unreachable pool degrades gracefully: claim_default still completes rather than reverting the whole default over an optional insurance top-up.

Why

• Implement proposal execution verification #531 — a failed cross-contract call left the protocol thinking a governance action had applied when nothing actually changed, with no way to retry.
• Implement quadratic voting in governance #530 — a handful of large token holders could otherwise dominate every proposal outcome regardless of how many distinct holders disagree.
• Implement governance-controlled oracle registry #532 — the protocol wants multiple oracle kinds (price feeds, identity, credit) and different providers per token, which a single address field can't represent.
• Integrate insurance pool with invoice_liquidity default flow #529 — LPs who opted into the insurance pool had no actual way to get compensated on a default; the hook was designed but never wired up.

How to test

• cargo test -p iln_governance — 97/98 passing (1 pre-existing failure, test_vote_receipt_available_within_ttl, unrelated — confirmed failing identically against unmodified main).
• cargo test -p invoice_liquidity --lib — 93/97 passing (4 pre-existing failures — test_upgrade_* x3 and test_admin_adds_token_with_different_decimals — confirmed failing identically against unmodified main logic; unrelated soroban-sdk API drift in tests_new_features.rs/tests_storage_layout.rs that predates this PR and isn't touched here).
• cargo build --workspace and cargo clippy -p iln_governance --all-targets -- -D warnings — clean.
• cargo fmt --all -- --check — no new diffs introduced by this PR (pre-existing formatting drift on main is left as-is, not touched).
• pnpm --filter @iln/sdk exec vitest run — new/touched SDK tests (admin.test.ts, governance.test.ts additions) pass; pre-existing unrelated failures in errors.test.ts, getTokenDecimals.test.ts, nft.test.ts, etc. are untouched by this PR.

Notes for reviewers

• invoice_liquidity's test suite (cargo test -p invoice_liquidity --lib) currently fails to compile on main due to pre-existing, unrelated soroban-sdk API drift in tests_new_features.rs and tests_storage_layout.rs (Address::random() no longer exists; a function's return type changed to Result<Vec<u64>, ConversionError> without call sites being updated). This isn't touched here — fixing it would be a separate, unrelated PR — but it's worth flagging since it means that crate's test binary hasn't actually been exercised in a while (the test/clippy CI jobs are also currently disabled via if: ${{ false }} in ci.yml, so this wasn't caught).
• Two test files (tests_access_control.rs, tests_oracle_freshness.rs, plus a few others: tests_benchmarks.rs, tests_multi_token.rs, tests_lp_priority_queue.rs, tests_appeal.rs, tests_multisig_admin.rs) exist in invoice_liquidity/src but aren't declared as mods in lib.rs, so they never actually compile/run as part of cargo test. Not fixed here (out of scope for these 4 issues and would need its own review — some of those files have their own pre-existing issues once wired in), but flagging since it's a meaningful gap.

[drips-wave]

@Asta-wizard Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits