mergefi_common::extend_ttl's threshold/extend-to constants (100_000, 500_000) have no derivation comment

[chonilius]

In contracts/common/src/lib.rs, extend_ttl_for_target has an extensive doc comment (30+ lines) explaining exactly where its numbers come from, including a reference to APPROX_SECONDS_PER_LEDGER and the specific issue (#56) that motivated it. The simpler extend_ttl function right above it — the one actually used on the overwhelming majority of storage writes across all three contracts — has zero explanatory comment for its own magic numbers (env.storage().persistent().extend_ttl(key, 100_000, 500_000)). README.md does explain the derivation elsewhere ("~29 days... 500_000 × 5 ÷ 86,400"), but that context isn't linked from the function itself, so a reader going straight to the source has no way to know these aren't arbitrary.

Add a short comment on extend_ttl (or a doc link to the README section) explaining the 100_000/500_000 derivation, matching the standard extend_ttl_for_target already sets in the same file.

[Jumongweb]

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

Hi maintainer, i will like to solve this issue

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

[vickachi]

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

hey maintainer i can work on this issue

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

[abbaskachia]

@abbaskachia 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 if it's still available.

I'll add a concise explanatory comment to extend_ttl in contracts/common/src/lib.rs documenting the derivation and purpose of the 100_000 threshold and 500_000 extension values, consistent with the existing documentation for extend_ttl_for_target.

I'll keep this strictly scoped to the missing source-level documentation without changing the TTL behavior or introducing unrelated changes. I'll run the relevant formatting and test checks before submitting the PR.

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

[rikkk-j]

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

hello miantainer, i would like to work on this

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

[drips-wave]

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

🧑‍💻 @rikkk-j: 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 🌊