v0.48.8

### Fixed

- **A recording that fail-closes on its consent announcement now says so on the CDR** (issue #440). `[recording.announcement]` is a fail-closed control: if the prompt can't play, the call doesn't record. That part worked on the mainline path (edge caveats found by post-merge review are tracked in #444/#445/#446). What didn't was the record of it — `docs/CONFIG.md` promised the call "shows up as `consent.announced = false`" and the code comment beside the fail-close said the same, but the consent block was gated on the two things that hadn't happened (an announcement having played, or the server having reported consent), so it was omitted entirely. A call whose consent prompt failed serialized identically to a call recording was never turned on for, which is exactly the distinction a recording-consent audit needs; the only trace was a WARN line. The block is now stamped `{ announced: false, announcement_ms: 0 }` whenever an announcement was configured and couldn't be played. The path also incremented **no metric at all** — the recording never finished because it never started — so a bad prompt file pushed to a fleet would silently stop it recording with nothing to alert on; `siphon_ai_recordings_total` gains a `result="blocked"` value, deliberately distinct from `failed` so a bad prompt and a bad disk stay separately alertable.

- **The CDR can now express whether a recording actually landed** (issue #441). `recording_path` was stamped whenever a recording was attempted — including a `failed` one where the file is incomplete or, as reproduced with an unwritable directory, never created at all — while the `ok`/`degraded`/`failed` outcome existed only in `siphon_ai_recordings_total`, a process-wide counter that cannot be attributed to a call. So a downstream uploader, retention job, or compliance export reading CDRs had no way to tell a path naming a good recording from one naming a file that does not exist. Records now carry `recording_result` (`ok` / `degraded` / `failed` / `blocked`), the same vocabulary as the metric. Same shape as #369: an outcome the daemon knew precisely and observed correctly, that the per-call record couldn't say.

  **CDR schema goes to version 8.** The JSON addition is additive-optional on its own, but the field also gives the CSV sink a **50th column** — appended at the end per its documented append-only rule, so ingestors keyed by column *position* survive, while one asserting an exact column *count* does not, which is CLAUDE.md §7.7's "could break parsers" bar. The bump also follows the v4 (`quality`) precedent of letting consumers gate on `version >= 8` rather than probe for the field — the natural thing for a compliance export reconciling recordings against calls. **Upgrade note:** a CSV ingestor pinned to 49 columns needs updating before this release; a JSON consumer tolerant of unknown fields needs nothing.

---

**Artifacts**

- Static musl binaries for `x86_64` and `aarch64` (`.tar.gz`).
- Debian packages (`.deb`) for `amd64` and `arm64` — `apt install ./siphon-ai_*_amd64.deb`.
- `SHA256SUMS` — verify with `sha256sum -c SHA256SUMS`.
- `*-sbom.cdx.json` — CycloneDX SBOM.
- `SHA256SUMS.cosign.bundle` — cosign keyless signature over the checksums.
- Container: `ghcr.io/thevoiceguy/siphon-ai:v0.48.8` (multi-arch, cosign-signed).

Verify the checksums signature:
```
cosign verify-blob --bundle SHA256SUMS.cosign.bundle \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp 'release.yml@' SHA256SUMS
```