Bind agent runs to threads, so the audit can answer "what happened here"

Depends on the threads issue.

A thread is only useful if the work it caused is attached to it. Right now a run and
an approval have no idea which conversation they belong to.

## The good news

`AuditEvent` already carries a `CorrelationId`. **A thread and a correlation scope are
the same concept** — a chain of work that came from one request. Use it rather than
inventing a second identifier.

## What to build

- `POST /api/sessions/{id}/agent-run` and `/desktop-run` accept an optional `threadId`.
When present, every audit event the run produces carries that thread's correlation id.
- `ApprovalRecord` gains a thread reference, so a permission request can be shown in
the conversation that caused it — and so the portal can say which job is blocked.
- `GET /api/audit-events` gains a `threadId` filter, alongside the `since`/`until`/`action`
filters added in #30.
- `GET /api/threads/{id}` returns the thread's messages **and** its audit events and
pending approvals, so one call renders the conversation.

## Acceptance

Starting a run from a thread and then reading that thread returns the run's audit
events and nothing from any other thread. A second owner's thread id returns 404, not
someone else's data.

Start with the threads issue and the existing AuditEvent CorrelationId, then trace POST /api/sessions/{id}/agent-run, /desktop-run, ApprovalRecord, GET /api/audit-events, and GET /api/threads/{id}. Confirm that thread-linked runs expose only their audit events and approvals, while another owner's thread id returns 404.

Written by the indexing model from the issue text.