Add Near-Real E2E Test Harness

> *This was generated by AI during triage.*

## Agent Brief

### Goal

Add an automated near-real end-to-end test harness for `opencode-threads` that exercises the plugin behavior without launching OpenCode or running a fake terminal.

### Why

The project is close to public release, but current verification is limited to `npm run typecheck` and `npm run build`. Most important behavior is embedded in the server plugin and `/threads` TUI route, making regressions hard to catch without manually launching OpenCode.

### Current Codebase Context

- `src/index.ts` contains the server plugin, `/threads` coordinator prompt rewrite, `spawn_threads` tool, session creation/fork compatibility logic, prompt sending, relation file writes, and current-session context extraction.
- `src/tui.tsx` contains the TUI plugin route plus message normalization, relation reading, session loading, grouping, nesting, keyboard handling, and session actions.
- Existing architecture issues #1 through #7 extract pure modules and adapters that should make this harness easier to build.
- There are currently no test files or test script in `package.json`.

### Scope

Introduce the smallest useful automated test setup that can run in CI/local development and exercise behavior through fake OpenCode plugin APIs instead of a real OpenCode process or terminal UI.

### Suggested Approach

1. Add a test runner that fits this TypeScript/Bun project with minimal dependency weight.
2. Add `npm test` and, if useful, a focused `npm run test:e2e` script.
3. Build lightweight fake OpenCode server/TUI API objects in test helpers.
4. Test the server plugin by invoking exported plugin hooks/tools directly with fake session APIs.
5. Test extracted pure modules where available, especially relation handling, prompt building, message normalization, session gateway compatibility, thread spawning, and catalog/grouping behavior.
6. Avoid snapshotting terminal rendering. Prefer asserting normalized models, API calls, relation writes, and hook/tool outputs.
7. Document the test strategy in `CONTRIBUTING.md` so contributors know this replaces manual OpenCode launch for most regression coverage.

### Acceptance Criteria

- [ ] `package.json` includes a test command that runs in this repo without launching OpenCode.
- [ ] Tests can instantiate or invoke plugin behavior with fake OpenCode APIs.
- [ ] Server-side coverage includes `/threads ` prompt injection and `spawn_threads` creating sessions, sending prompts, and recording parent relationships.
- [ ] TUI-adjacent coverage exercises list-model/catalog behavior through pure data or extracted helpers, not terminal rendering.
- [ ] Relation-store tests cover missing file, invalid entries such as `undefined`, and successful writes.
- [ ] Message-normalization tests cover unstable OpenCode message shapes and filtering tool/lifecycle noise.
- [ ] `CONTRIBUTING.md` explains the automated test loop and what still requires manual OpenCode testing.
- [ ] `npm test`, `npm run typecheck`, and `npm run build` pass.

### Out Of Scope

- Launching the real OpenCode binary.
- Running a fake terminal or recording TUI snapshots.
- Full browser-style E2E tests.
- Rewriting all architecture modules in this issue unless required to expose testable seams.

### Dependencies

Best implemented alongside or after the extraction issues #1 through #7, but an agent can start by adding the harness and first server-level tests before every extraction lands.