fix(cogs): Account for HV resumable upload markers

[lcian]

Report resumable upload marker creation and successful deletion through the existing ChangeStream in the Bigtable and in-memory HV backends.

Note that the ID we send through is the same as the LT revision, but the shared_resource_id for the records will be different, therefore there cannot be a clash.
Please let me know if we should do this differently.

Earlier I've opened #673 which also introduced a new kind of record for resumables and sends those through on creation and completion/cancellation.
It turns out that we might not need that for GC after all (based on yesterday's meeting), moreover GCS doesn't actually bill you for storage for incomplete resumable, so that would not even be correct from a COGS perspective.

Closes FS-563

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.37%. Comparing base (0abc6bf) to head (6a46ac2).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #674      +/-   ##
==========================================
- Coverage   91.38%   91.37%   -0.01%     
==========================================
  Files         117      117              
  Lines       24056    24056              
==========================================
- Hits        21983    21982       -1     
- Misses       2073     2074       +1     

Components	Coverage Δ
Rust Backend	94.89% <100.00%> (ø)
Rust Client	81.70% <ø> (ø)
Python Client	93.81% <ø> (ø)

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[linear-code]

FS-563

[lcian]

This is wrong, we still need to record the payload for GC, as done in #673.