Eliminate runtime panics in the daemon paths (agent/worker/registry)

## Summary

The long-running services (agent, worker, registry) panic on failures instead of returning typed errors. A panic kills a `tokio-runtime-worker` thread and dumps a raw backtrace at the user rather than surfacing an actionable gRPC `Status`. This is the single highest reliability-per-effort fix for the core daemon.

_This issue supersedes and combines #226 (which reported the original symptom) with the scoped action plan from a recent project review._

## Original report (from #226)

When the worker services hit a failure, they panic their guts into stdout/stderr:

```
thread 'tokio-runtime-worker' panicked at cli/src/command/start/agent.rs:332:14:
failed to push: Status { code: Internal, message: "failed to write store path: Os { code: 2, kind: NotFound, message: \"No such file or directory\" }", metadata: MetadataMap { headers: {"content-type": "application/grpc", "date": "Fri, 23 May 2025 16:53:17 GMT"} }, source: None }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```

This should be using `tracing::error!()` with proper `Result` handling instead, because `anyhow::bail!(...)` in these spawned tasks just panics outright.

## Scope

There are ~119 `unwrap()/expect()` call sites (plus a `panic!`/`unreachable!`) across `cli` + `sdk/rust`. The priority is the ones reachable from live request handling.

### Daemon hotspots

- [ ] `cli/src/command/start/agent.rs:430` — `client_archive.push(request).await.expect("failed to push")`
- [ ] `cli/src/command/start/agent.rs:474` / `:522` / `:647` — `request.artifact.unwrap()`, source-digest `unwrap()`, `artifact_sources.last().unwrap()`
- [ ] `cli/src/command/start/worker.rs:162` — `artifact_source.digest.as_ref().unwrap()`
- [ ] `cli/src/command/start/worker.rs:397-415` — UTF-8 char-boundary logic in the output-rewriting code (panics on edge-case byte boundaries)
- [ ] `cli/src/command/start/registry.rs` — ~18 `unwrap()` call sites in the registry service
- [ ] Remaining `start::*` request handlers (store/keys/etc.)

## Approach

- Convert panicking call sites in request paths to return `tonic::Status` (gRPC) or `anyhow::Result`, logging with `tracing::error!()` at the boundary rather than panicking inside spawned tasks.
- Prefer `?` + explicit error mapping over `unwrap()/expect()`; reserve `expect()` for genuine invariants with a message explaining why it cannot fail.

## Regression guard

- [ ] Once the `start::*` modules are clean, add `#[deny(clippy::unwrap_used, clippy::expect_used)]` (module-scoped) so panics can't creep back into the daemon paths.

## Related

- Combines/supersedes #226.
- Closely tied to #499 (unit-test coverage) — most of the call sites that need converting live in the currently-untested worker/store/backend modules, so the two should land together.

Start with the named daemon files: cli/src/command/start/agent.rs, worker.rs, and registry.rs, focusing on the listed unwrap()/expect() sites in live request handling. Trace how those handlers return tonic::Status or anyhow::Result, then convert panics to explicit error returns and boundary logging. Done means the start::* daemon paths no longer panic at those call sites and the module-scoped clippy deny guard can be added.

由索引模型根據 Issue 內容生成。