Contract: Optimize TaskConfig storage footprint

[wheval]

Summary

• TaskConfig.interval: u64 -> u32. It's seconds between executions, never needs more than ~136 years of range - unlike last_run (a ledger timestamp, kept u64 to match env.ledger().timestamp()) or gas_balance (a token amount, kept i128). Left blocked_by/yield_strategy as u64 since every other ID in the contract (task IDs, portfolio IDs, etc.) is u64 - shrinking just one would be an inconsistent, riskier change for a smaller win.
• Added test_task_config_storage_footprint, a benchmark that measures a TaskConfig's actual XDR-serialized size (the thing that determines ledger storage/rent, as opposed to the CPU/memory test_gas.rs's existing benchmarks measure) and locks it in as a regression assertion.
  • Measured: 412 bytes before this change, 408 bytes after - a 4-byte reduction per stored TaskConfig, matching the XDR ScVal encoding difference between U64 (4-byte type tag + 8-byte value) and U32 (4-byte type tag + 4-byte value).
• Fixed track_gas() in test_gas.rs along the way: it computed cpu_instruction_cost()/memory_bytes_cost() but discarded them without printing, behind a stale "println not available in wasm tests" comment (these are native cargo test tests, not wasm - eprintln! works fine). It now actually prints via std::eprintln!, so cargo test -- --nocapture benchmarks something instead of nothing.

Closes #674

Test plan

• cargo test --lib - 136 tests pass
• cargo test test_task_config_storage_footprint -- --nocapture manually re-run against interval: u64 (temporarily reverted) to get the "before" number, then restored - see commit message for both measurements