feat(settings): add 'deacon settings get/set' command for user-level settings

## Background

Feature `016-host-ca-injection` introduces deacon's first user-level setting (`hostCa`) persisted to `{user_data_folder}/settings.json` (sibling of `trusted_workspaces.json`, atomic temp-file + `fs::rename` write).

During planning we considered shipping a minimal CLI write surface (`deacon settings get/set`) alongside the file. We've decided to **defer** that command: for the initial `016` work the settings file is **read-only from deacon's perspective** (machine owner / IT hand-edits or provisions it, or sets it via the `--inject-host-ca` flag / `DEACON_INJECT_HOST_CA` env var per-invocation). This keeps `016` focused on the CA capability itself.

## Proposed work (this issue)

Add a consumer-side machine-config command:

```
deacon settings get # print a user-level setting (text or --output json)
deacon settings set # persist a user-level setting (atomic write)
```

- Supported key initially: `hostCa` (`auto` | absolute PEM path). Unknown keys fail fast listing valid keys (Constitution IV).
- Honors `--user-data-folder`; touches only the user-data folder, never workspace files (machine-side trust boundary).
- Reuses the atomic write pattern from `crates/core/src/cache/disk.rs::save_index`.
- Output stream contract: result on stdout, logs on stderr; `--output json` emits a single JSON object.

## Scope notes

- This is consumer-side **machine** configuration (not feature authoring), so it's within Consumer-Only Scope (Constitution II).
- The `Settings` struct + atomic load/save land in `016` (needed to *read* `hostCa`); this issue only adds the **write/inspect CLI surface** on top.

## References

- `specs/016-host-ca-injection/research.md` — Decision 6
- `specs/016-host-ca-injection/contracts/cli.md` — §4