feat: add get_effective_rule API with full resolution chain

[samjay8]

Closes #524

Summary

• get_default_rule only returns the stored global default — when no default is stored but governance provides a fee config, it says None while the write/payment paths actually resolve the governance rule. This divergence misleads frontends about config state.
• Added get_effective_rule(merchant) that always returns a rule by following the full resolution chain: merchant-specific → global default → governance fee config → bootstrap fallback.
• Documented the difference between stored and effective rule APIs.

Scope

Does not modify existing get_default_rule or get_settlement_rule — purely additive. Does not touch write paths or payment logic.

Testing

• cargo check --workspace — passes
• Two new integration tests:
  • get_effective_rule_resolves_governance_fees_when_no_default_stored — verifies governance fee config is resolved when no default rule is stored
  • get_effective_rule_returns_merchant_rule_when_set — verifies merchant-specific rule takes priority
• Note: cargo test -p settlement_contract --lib has pre-existing compilation errors in upstream's integration_tests.rs (unrelated type mismatches from recent PRs fix: scope payment references per merchant (closes #493) #657–test: cover governance authorization paths #663). Source code and new tests compile cleanly.

Files changed

• settlement_contract/src/settlement.rs — added get_effective_rule method with documentation
• settlement_contract/src/tests/integration_tests.rs — added two integration tests

[drips-wave]

@samjay8 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