[ENH](storage): Decouple latency stopwatch from tracing

[domenkozar]

Summary

• move the storage latency stopwatch into chroma-storage
• remove the chroma-tracing dependency from chroma-storage
• ensure explicit stopwatch completion records its histogram exactly once
• preserve drop-based recording and cover both paths with regression tests

Motivation

Storage only needs std::time::Instant and OpenTelemetry histograms for these measurements. Depending on the broader tracing crate pulls the full tracing implementation into storage consumers unnecessarily.

The existing finish method also records once directly and then records again when the consumed stopwatch is dropped. The storage-local implementation tracks completion so each timer contributes exactly one sample.

Validation

• cargo fmt --all -- --check
• cargo test -p chroma-storage --lib -- --skip test_k8s_integration
• cargo test -p chroma-storage --doc
• cargo clippy -p chroma-storage --all-targets --all-features --keep-going -- -D warnings -D clippy::large_futures -D clippy::all
• verified the normal chroma-storage dependency tree no longer contains chroma-tracing, fastrace, or fastant

The self-contained storage suite passes 11 tests; 27 Tilt-dependent tests are filtered. The S3 and GCS integration targets require external services or credentials.

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[github-actions]

Reviewer Checklist

Please leverage this checklist to ensure your code review is thorough before approving

Testing, Bugs, Errors, Logs, Documentation

• Can you think of any use case in which the code does not behave as intended? Have they been tested?
• Can you think of any inputs or external events that could break the code? Is user input validated and safe? Have they been tested?
• If appropriate, are there adequate property based tests?
• If appropriate, are there adequate unit tests?
• Should any logging, debugging, tracing information be added or removed?
• Are error messages user-friendly?
• Have all documentation changes needed been made?
• Have all non-obvious changes been commented?

System Compatibility

• Are there any potential impacts on other parts of the system or backward compatibility?
• Does this change intersect with any items on our roadmap, and if so, is there a plan for fitting them together?

Quality

• Is this code of a unexpectedly high quality (Readability, Modularity, Intuitiveness)