Decompose the insurance monolith (~ 3300 LOC) into claim, policy and registry modules

[nanaf6203-bit]

Problem Statement

contracts/insurance/src/lib.rs mixes premium calculation, claim evidence handling, fraud detection, risk assessment, Sybil heuristics, premium property tests, and lazy reinsurance in one ~3300-line file.

Why it matters

Insurance has the highest gas surface and audit complexity in the workspace; the monolith blocks unit-level coverage targets and complicates independent verifier reviews.

Technical Context

• mod premium_engine — premium math.
• mod claim_pipeline — claim submission + evidence.
• mod fraud_detection — fraud heuristics.
• mod risk_assessment — risk scoring.
• mod sybil_defense — anti-Sybil mapping.
• mod lazy_reinsurance — quarterly reinsurance lookups.

Expected Outcome

• Each sub-module has its own message group.
• Sub-modules are randomly accessible via contract.feature_x() calls.
• Public API surface unchanged.
• Storage layout preserved or migrated via documented mapping.

Acceptance Criteria

1. Every existing #[ink::test] continues to pass.
2. Each sub-module independently exports at least one message.
3. cargo doc --no-deps renders an unambiguous doc-tree.
4. cargo clippy reduces warnings materially (target: ≥ 30 fewer).

Implementation Notes

Split by message-level boundaries: each sub-module owns its storage map and re-exports. Use storage::Mapping::default() defaults for non-init constructors.

Files or modules likely to be affected

contracts/insurance/src/lib.rs, new split files.

Dependencies

#3 (do the same for property-management first to learn).

Difficulty level

HARD.

Estimated effort

XL (~3 engineer-weeks).

[kike-alt]

@kike-alt has applied to work on this issue as part of the Stellar Wave Program's 7th wave.

Hi, I'd like to work on this issue.

I'm a software engineer with strong experience in JavaScript and building scalable web applications. I'm comfortable working across the stack, writing clean, maintainable code, and collaborating in open source environments.

I've reviewed the issue and I'm confident I can implement a solid solution while following the project's conventions.

Please assign this issue to me, I'd be happy to contribute.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @kike-alt to this issue.

[drips-wave]

Congratulations, @kike-alt! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on July 30, 2026.

🧑‍💻 @kike-alt: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊

[drips-wave]

This issue has been completed by @kike-alt as part of the Stellar Wave Program's 7th Wave 🥳

😎 @kike-alt: You earned 200 Points for completing this issue! After the current Wave ends, you'll be eligible for a percentage of the Wave's reward pool based on the percentage of total points you've earned. Learn more here. You can also Leave a review to share your experience working on this issue.

🧑‍💻 Repo maintainers: How'd the contributor do? Leave a review to share your experience working with them.