refactor: StorageManager::extend_project_full_ttl called from lib.rs but TTL extension logic is scattered

[Naomi-Gift]

TTL extension calls are scattered throughout admin_manager.rs, project_registry.rs, verification_registry.rs, and lib.rs. A consistent pattern should be established where each module is responsible for extending its own TTLs, and StorageManager provides helpers. The inconsistency makes it easy to forget TTL extensions when adding new storage writes.

[Bidex-cmyk]

I would like to apply for issue #501 to refactor and consolidate the TTL extension pattern across Dongle-Smartcontract. I have strong experience developing Soroban smart contracts in Rust, managing contract instance/persistent state lifetimes, and establishing clean encapsulation patterns for on-chain storage.

Here is my planned execution strategy:

StorageManager Helper Consolidation (src/storage.rs / StorageManager):

Standardize helper methods inside StorageManager for bump/TTL extension calls across instance, persistent, and temporary storage keys.

Ensure StorageManager exposes clear, domain-specific TTL extension helpers so individual modules can extend their own state consistently without repeating manual bump boilerplate.

Module-Level TTL Encapsulation:

admin_manager.rs: Encapsulate admin state TTL bump logic directly within admin storage mutations.

project_registry.rs: Refactor project registry functions to automatically extend project state TTLs upon reads and writes using StorageManager helpers.

verification_registry.rs: Centralize verification record TTL extensions within the module's storage accessors.

lib.rs: Clean up top-level contract entry points by removing scattered TTL extension calls in favor of domain module encapsulation.

Testing & Verification:

Run existing unit and integration test suites to verify that contract function behaviors and state persistence remain unchanged.

Add test coverage ensuring TTL extensions trigger correctly across all state updates and modules.