[Quality-2][High] Prevent replay of factory initialization calls

[greatest0fallt1me]

Summary

Implement Prevent replay of factory initialization calls as a production-ready change in Creditra/Creditra-Contracts.

Why this matters

This behavior needs a deterministic, reviewable implementation so normal operation and adverse conditions do not produce silent data loss, inconsistent state, security regressions, or an unrecoverable user experience. Preserve least privilege, input validation, and confidentiality; cover abuse and authorization boundaries.

Scope

Trace the relevant entry points, state model, and failure paths; implement the smallest complete design; preserve public interfaces unless a compatibility plan is included; and document important invariants in code.

Priority

High

Acceptance criteria

• The intended behavior is deterministic for valid, invalid, duplicate, and boundary-case inputs.
• Authorization, validation, and state-transition invariants remain enforced.
• Retries, partial failure, and concurrent execution cannot produce an unsafe or inconsistent result.
• Focused tests cover the success path, rejection paths, boundary conditions, and regression scenario.
• Existing callers remain compatible, or the PR includes a tested migration path.
• Relevant logs, metrics, or user-visible errors make failures diagnosable without exposing sensitive data.

Validation

Run the repository's focused test suite and CI checks. Include evidence for normal operation, invalid input, repeated requests, concurrency or timing boundaries, and failure recovery where applicable.

Non-goals

• Typo-only, formatting-only, documentation-only, or cosmetic changes.
• Unrelated refactors, dependency upgrades, or broad rewrites.
• Removing safeguards or weakening validation to make tests pass.

Contributor application

Before coding, describe the affected modules, proposed state/invariant changes, test strategy, compatibility considerations, and an estimate. Wait for assignment before starting implementation.

PR requirements

Use a feature branch and include Closes #<issue-number>. Address every acceptance criterion, map each criterion to code and tests, explain security and failure-mode handling, and ensure CI passes.

Quality review

A maintainer will assess correctness, completeness, test depth, compatibility, observability, and handling of adverse cases. A substantive implementation is required; merge or CI status alone does not guarantee reward eligibility.

[Audukuma]

@Audukuma has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hello, I would love to work on this issue, please assign it to me

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

[temitope-007]

@temitope-007 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi maintainer

I'd like to work on this issue

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

[itoro2]

@itoro2 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi, I’d like to work on this issue. I’ve reviewed the requirements and understand what needs to be implemented. I’ll first inspect the existing code, make the necessary changes, add or update tests where appropriate, and submit a clean, well-documented PR. I’m ready to start immediately.

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

[drips-wave]

Congratulations, @temitope-007! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @temitope-007: 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 marked as completed by a Drips Wave moderator for @temitope-007 as part of the Stellar Wave Program's 8th Wave 🥳

Moderator's reason: [Auto-assessed] The contributor temitope-007 successfully implemented the requirements for Issue #1141 in PR #1204, introducing one-shot factory initialization with a persistent marker (FactoryInitialized), a separate rotation path (rotate_factory_contract), and thorough test coverage confirming that replays and unauthorized rotations are rejected. All CI checks are passing, the code diff is clean and fully reviewable with 100% diff coverage, and there are no maintainer objections across any channel.

😎 @temitope-007: You earned 100 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.

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

ℹ️ Note: This issue was marked complete via moderation. Points were issued even though the GitHub issue remains open.