Blocker model and SQLite store: structured record, park/list/resolve

[Ryan-Atkinson87]

The structured blocker record and its SQLite store — the durable state that escalation, PR surfacing, and Telegram blocker-replies all read.

Spec: §9.1 Blocker behaviour, §18.3 Per-issue state markers, §2 (SQLite blocker records).

Acceptance criteria

• Structured blocker record: type, what's blocked (issue/wave ref), why, what's needed to unblock, created-at, status (parked/resolved) (§9.1).
• Persisted in the engine's SQLite store (§2), separate from the trackers, integrated with the existing state store (SQLite state store: schema baseline, WAL mode, connection management #3).
• Operations: record a blocker, list parked blockers (for a wave/run), resolve a blocker.
• Re-recording the same blocker is idempotent — no duplicate parked record for the same issue.
• Explicit success/failure paths; no silent pass.
• Unit tests for record / list / resolve and idempotent re-record.

Depends on: #3