maintenance: reuse cached embedding assets on daemon startup

[totocaster]

Affected components

• crates/arrowhead-daemon/src/runtime.rs (download_embedding_assets / embedding startup state)
• hf-hub cache integration used by the daemon

Risk and impact

The daemon calls hf_hub::ApiRepo::download_with_progress for every embedding asset at every startup. In hf-hub 0.4.3 that API performs a network download even when the complete blob and snapshot pointer already exist locally. For the fast preset this re-downloads roughly 90 MB and delays indexing on each login or restart.

A transient response-body failure reproduced on a complete, valid cache. The daemon then recorded an error-severity embedding_download issue and continued without an embedding pipeline, temporarily disabling semantic and hybrid freshness until another restart completed the download.

Proposed fix

Consult the hf-hub cache before invoking download_with_progress. Validate that every required cached pointer resolves to a regular asset, emit the existing cached-completion status event, and call the progress downloader only for a true miss or invalid cache entry. Preserve resumable partial-download behavior and actionable failure reporting.

Suggested tests

• Start with a complete model cache and a network client that must not be called; assert cached completion and pipeline initialization.
• Start with one missing or corrupt asset; assert only that asset downloads and the final cache is usable.
• Simulate a transient partial response; assert a later retry resumes safely without damaging a previously complete blob.
• Verify offline startup with a complete cache keeps semantic and hybrid search available and reports no error issue.

Why this was not implemented automatically

This was discovered during post-release installation validation. Correcting it changes the embedding download and cache state machine and requires controlled offline and network-failure coverage; it is broader and riskier than a last-minute maintenance edit.