feat: expose CAS client factory and chunk cache re-exports

[XciD]

Context

These changes support the hf-mount project, which needs direct access to CAS client types.

Summary

• Changed create_remote_client visibility from pub(crate) to pub
• Added re-exports for CasClient, ChunkCache, CacheConfig, and get_cache in xet_data::processing

[rajatarya]

Clean, minimal change — 4 lines to unblock hf-mount. A couple of thoughts:

API surface: This promotes create_remote_client and several xet_client types to the public API of xet_data. Once hf-mount depends on these re-exports, they become harder to change. Is there a reason hf-mount can't depend on xet_client directly instead of going through xet_data as a pass-through for types it doesn't own? If there is (e.g. TranslatorConfig coupling), worth a comment explaining the intent.

Client as CasClient rename: Reasonable ergonomic choice, but diverges from the name used everywhere else in xet-core internally. Just flagging — not blocking.

nit: create_remote_client is now pub with no doc comment. Since this is becoming part of the external-facing API for downstream consumers, a brief doc string would help future readers.

Overall: small and safe. The main question is architectural (direct dep vs re-export).