test(daemon): add coverage for voxora-hf 0.6.1 / 0.6.2 error paths

Two new voxora-hf error variants shipped in the v0.7.2 cycle
(adopted in PR for v0.7.2) are not exercised by any telora integration
test:

- `voxora-hf 0.6.1`'s `HfError::RetriesExhausted { url, attempts,
last_error }` (closes `airvzxf/voxora#113`)
- `voxora-hf 0.6.2`'s `HfError::LockUnavailable { path, attempts,
message }` (closes `airvzxf/voxora#185`)

The existing `telora-daemon/tests/voxora_020_resolution.rs` only
exercises the cache-hit / `.complete`-marker fast path and
deliberately uses `base_url("http://127.0.0.1:1")` so the network
slow-path "can never succeed" — neither retry exhaustion nor
lock contention is hit.

**Proposed fix:**

Add `wiremock = "0.6"` (or `httpmock`) as a `dev-dependencies`
of `telora-daemon/Cargo.toml` and write tests against:

1. `HfError::RetriesExhausted` surfaces as `AsrError::network(url,
"retries exhausted after 3 attempt(s): …")` upstream, then
`RegistryError::Parse("source resolve: …")`, then
`anyhow!("voxora: …")` to the operator.
2. Two concurrent `HuggingFaceSource::resolve` calls against the
same `(model_id, revision)` serialise on `/.lock`
(the second one observes `LockUnavailable` if the first is
still in flight past the `LOCK_ATTEMPTS × LOCK_MAX_DELAY_MS`
budget).

Tracked separately to keep the v0.7.2 dep-bump PR focused.

Start with telora-daemon/tests/voxora_020_resolution.rs and telora-daemon/Cargo.toml, then trace the existing HuggingFaceSource::resolve integration path. Add coverage for retries exhausted and concurrent lock contention, verifying the documented AsrError, RegistryError, and operator-facing anyhow messages; done means both error paths are exercised by integration tests.

Written by the indexing model from the issue text.