Scale keep_alive TTL bumps to match each contract's real lifecycle

[avqor]

Closes #11

---

escrow's keep_alive/extend_deadline already scale TTL toward the stored deadline instead of the flat ~29-day bump, but that never made it to milestones, even though Milestone stores its own deadline too — its keep_alive docstring even claimed otherwise. Fixed that, and gave maintenance-pool a different treatment since pools have no deadline at all: keep_alive there now just extends as far as the network allows in one call, since the whole point of the contract is being open-ended.

Also noticed none of the three keep_alive functions ever touched instance storage, only the record itself. That means a quiet pool or milestone being kept alive perfectly fine could still lose the whole contract once Admin/Treasury/FeeBps expired. Fixed that too.

Added a doc on how Soroban TTL/archival/restoration actually works and what the old 100_000/500_000 numbers translate to in real time per contract, plus tests that advance the ledger sequence directly to prove records survive long idle periods with periodic keep_alive pings (and decay to the bare minimum TTL without them).

[vercel]

@avqor is attempting to deploy a commit to the chonilius' projects Team on Vercel.

A member of the Team first needs to authorize it.

[drips-wave]

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