chore: review storage footprint and compute-cost of hot paths (#144-#147)

[maztah1]

Summary

Four related performance/footprint investigations against intent_settlement. Each issue asked for a review first and a code change only if net-positive; in all four cases the finding is that no code change is warranted, and each is documented under docs/ so the reasoning is on record.

Issue	Area	Finding
#147	IntentRecord / SolverRecord field types & ordering	No change. #[contracttype] structs serialize as a key-sorted ScMap, so field ordering has zero footprint effect. Every integer field is already at the correct width — u64 timestamps are SDK-native, and the i128 amount fields are bounded by MAX_AMOUNT (1e30 > u64::MAX) so they genuinely need 128 bits (u128 saves 0 bytes). The only real wins are structural (SolverRecord.address duplicates its storage key; fill_amount vs total_filled look redundant) and belong in their own issues.
#146	compute_intent_id fixed-size preimage buffer	No change. The preimage is variable-length (Address/String XDR), and to_xdr must cross the host boundary regardless, so a fixed-size buffer doesn't cleanly apply. The only collapsible part — packing the 3 trailing integers into one append — removes ~2 of ~8 host calls, a sub-1% effect dominated by sha256 + to_xdr.
#145	Unconditional extend_ttl on every write	No change. extend_ttl(threshold, extend_to) is already conditional inside the host: below-threshold TTL is a subtract-and-compare with no ledger write and no rent. A guest-side pre-check would call get_ttl (another host call) and only add cost.
#144	Splitting the single instance-storage entry	No split. Confirmed Soroban keeps all instance storage in one ledger entry (already noted in docs/ttl-constants-rationale.md), so every instance write rewrites the whole map — but that map is a dozen small scalars. Moving TotalIntents/TotalVolume to their own persistent entries adds a full extra ledger read + write + TTL/rent lifecycle per call — strictly more I/O, not less. The counter update is already dwarfed by the persistent IntentRecord write every submit_intent does.

Notes

• Benchmark compute_intent_id's Bytes preimage construction against a fixed-size buffer #146 and Evaluate splitting the single instance-storage entry into multiple entries #144 additionally ask for a measured baseline via the resource-benchmarking harness. That harness does not exist in this repo (same blocker as docs/149-resource-cost-per-entrypoint.md); the docs record what can be measured once it lands and the conditions under which each change would become worth revisiting.
• No source changes, so no test changes — no field type, hashing input, TTL behavior, or storage key changes.

Changes

• docs/147-intentrecord-solverrecord-field-footprint-review.md
• docs/146-compute-intent-id-preimage-buffer-benchmark.md
• docs/145-ttl-bump-frequency-review.md
• docs/144-instance-storage-layout-review.md

Closes #147
Closes #146
Closes #145
Closes #144

[drips-wave]

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