[BUG]: Defer home path resolution

[wiliyam]

Description of changes

• Improvements & Bug fixes
  • Defer the default ONNX model cache path until the embedding function is instantiated.
  • Defer the telemetry user ID path until it is used, inside its existing failure-safe block.
  • Keep both class attributes available so callers and tests can still override their paths.

This fixes #1962. A plain import chromadb currently raises when the process has no resolvable home directory, as can happen with systemd dynamic users and distroless containers, even when neither the ONNX embedding function nor telemetry storage is used.

Test plan

• New subprocess regression fails on the upstream base with RuntimeError: no home and passes with this patch.
• pytest -q chromadb/test/test_import.py (1 passed)
• black==23.3.0 --check on the three changed files
• python -m compileall on the three changed files

The initial editable build could not run in this environment because its Rust build requires a system cc linker. The focused test was run against the source tree with the Python dependencies installed separately.

Migration plan

No migration or compatibility action is required. Explicit DOWNLOAD_PATH and USER_ID_PATH overrides continue to take precedence.

Observability plan

No new runtime instrumentation is needed; this only moves path resolution from import time to first use.

Documentation Changes

None. No user-facing API changes.

This contribution was AI-assisted and manually reviewed. The reproduction and reported test results were run locally.

[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)