Feature: Thread status (open/resolved) per incident investigation

## Context
In Faultline, a thread represents a single incident / investigation (one thread per incident). When the investigation is complete and the incident is handled, the thread should be explicitly closed.

## Problem
Without a thread status, it’s hard to tell which incident investigations are still active vs completed, especially over time.

## Proposal
Add a status field to each thread:
- **open** (default)
- **resolved** (investigation complete / incident handled)

## UX
- Show a status pill on the thread header and in the thread list.
- Quick actions:
- **Mark resolved** (closes the investigation)
- **Reopen** (if the incident regresses or investigation resumes)
- Thread list filters: **All / Open / Resolved**
- Optional: show only Open by default.

## Behavior
- New thread = `open`
- Mark resolved = `resolved`
- If someone posts a new message in a resolved thread:
- **Auto-reopen** the thread (recommended), or
- keep it resolved and require manual reopen (less ideal for incident workflows).

## Acceptance criteria
- A thread can be marked resolved and reopened.
- Thread list clearly separates active vs completed investigations.
- Status persists and is reflected across reloads/devices.
- Filtering by status works.

## Why this matters
Status turns the thread list into a lightweight incident timeline: what’s active now vs what’s already completed, without scanning message history.

Start by locating the thread model and the code for the thread header and thread list. Trace how thread data is persisted and reloaded, then implement the status behavior and verify that marking resolved, reopening, auto-reopening on new messages, and filtering produce the acceptance-criteria results.

Written by the indexing model from the issue text.