fix(contracts): preserve accrued vest time on stream top-up (closes #786)

[samjay8]

(closes #786)

Summary

top_up_stream was unconditionally resetting stream.last_update_time to the
current ledger timestamp on every call. Since calculate_claimable uses
last_update_time as the accrual anchor (elapsed = effective_now - last_update_time), this silently discarded any vested-but-unwithdrawn
balance the moment a top-up happened.

Concrete impact: for a 1000-token / 1000s stream (rate 1/s), if the recipient
had 900 unwithdrawn tokens vested at t=900 and the sender called
top_up_stream(+100), last_update_time jumped to 900, zeroing
get_claimable_amount. A subsequent cancel_stream at t=901 would then pay
the recipient only 1 token and refund 1099 to the sender — letting the
sender reclaim ~899 tokens the recipient had already earned.

Fix

• Removed the stream.last_update_time = env.ledger().timestamp() assignment
  in top_up_stream (contracts/stream_contract/src/lib.rs) so prior accrued
  time is preserved across top-ups, including while a stream is paused
  (last_update_time is never pushed past paused_at).

Tests added

• test_top_up_preserves_already_accrued_claimable — after
  create_stream(1000, 1000s), advancing 900s and topping up by 100 keeps
  get_claimable_amount at 900 instead of dropping to 0.
• test_top_up_then_cancel_pays_pre_topup_accrued — topping up and
  immediately cancelling pays the recipient exactly the pre-top-up accrued
  amount.
• test_top_up_while_paused_does_not_advance_last_update_time — topping up a
  paused stream does not push last_update_time past paused_at, and
  claimable amount still reflects only the time accrued before the pause.

Scope

• Out of scope per the issue: protocol fee logic and frontend/backend top-up
  wiring were left untouched.
• Files touched: contracts/stream_contract/src/lib.rs,
  contracts/stream_contract/src/test.rs.