fix(grpc): address implementation mismatches between REST and gRPC handlers

Summary

Several gRPC handlers have behavioral differences from their REST counterparts:

1. DeleteSecret does not call notifyModelsChanged

REST DELETE /api/secrets/:key calls state.notifyModelsChanged('secret_deleted') after deleting a secret. The gRPC DeleteSecret handler does not, meaning model state may become stale after secret deletion via gRPC.

2. ListProviders ignores workspace_paths

ListProvidersRequest accepts workspace_paths but the handler ignores them, always returning user-level providers only. REST GET /api/providers has the same limitation, but the proto implies workspace awareness.

3. GetStatus does not populate registered_mcp_servers

The DaemonStatus proto message includes registered_mcp_servers but the GetStatus handler never sets it.

4. SetSecret ignores the store field

SetSecretRequest includes a store field (keychain vs env) but the implementation always writes to the default secret store.

Proposal

Fix each handler to match the documented proto contract or, where the REST API has the same gap, align both and update the proto to remove misleading fields.

Context

Identified during gRPC config parity audit in #32.

Start by comparing the gRPC handlers for DeleteSecret, ListProviders, GetStatus, and SetSecret with their REST counterparts and the corresponding proto fields. Verify the intended behavior for workspace_paths, registered_mcp_servers, store, and model-change notification, then run the relevant handler tests if present. Done means the APIs match the documented contract, or misleading fields are removed and both APIs and the proto are updated consistently.