Fold repair-item library into comments + repair-items/contractor-types UI

[important-new]

Summary

Folds the standalone recommendations repair-item library into comments (matching the competitor model where severity + repair recommendation + cost estimate + recommended contractor type live inside deficiency comments), retires the recommendations table, and adds the full UI on top. Spec: docs/superpowers/specs/2026-06-12-comments-repair-fold-design.md. Plans: docs/superpowers/plans/2026-06-12-comments-repair-fold-backend.md (Plan 1) + docs/superpowers/plans/2026-06-13-comments-repair-fold-ui.md (Plan 2).

Backend (Plan 1)

• Migration 0030: 4 repair columns on comments (repair_summary, estimate_min_cents, estimate_max_cents, recommended_contractor_type_id) + new contractor_types table; copies recommendations → comments reusing ids (finding snapshots still resolve); seeds the standard 10 contractor types per tenant; drops recommendations last.
• /api/recommendations re-implemented as a thin alias over repair-item comments (repair_summary IS NOT NULL); new /api/contractor-types CRUD + reorder. Starter-content seeds + tenant-purge updated.

UI (Plan 2)

• /repair-items: real CRUD (severity / cost estimate / repair summary / recommended-contractor dropdown), replacing the read-only stub.
• Settings → Contractor Types: CRUD page with inline rename + up/down reorder.
• Comment CRUD: schemas + handlers now carry the 4 repair fields (were silently dropped).
• Editor attach flow: inspectors attach repair-item comments to a finding; each attach snapshots {recommendationId, estimateSnapshotMin/Max, summarySnapshot, contractorTypeSnapshot, attachedAt} into inspection_results.data[itemId].recommendations[], reusing the existing whole-blob save-all persistence (no new write endpoint) and the offline diff3 union.
• Report: attached repair items render on the report card with a contractor-type pill + cost estimate; the aggregate endpoint carries contractorTypeSnapshot.

Notable fix

The aggregate endpoint GET /api/inspections/:id/recommendations double-counted every attached item, because the editor stores each result under both a composite key and the bare itemId (how all mutations persist) while the aggregate flattened all keys. Fixed by normalizing keys via parseFindingKey and deduping by (itemId, recommendationId) — preserving the same recommendation legitimately attached to two different findings. The report reader (single per-item result) was confirmed immune.

Scope notes

• The per-defect RECOMMENDATION_CATEGORIES slug mechanism and the client-facing Repair Request feature (repair-requests.ts) are a separate system and are untouched.
• The "repair fields in the canned-comment library drawer" sub-item was intentionally descoped as redundant — /repair-items is the canonical repair-item editor.

Test Plan

• npm run type-check (app + api) — exit 0
• npm run db:check — EQUIVALENT (70/70 tables, no drift)
• npm run test:unit — 1657 passed / 8 skipped (incl. 13 new: alias contractor-type, comment repair-field schemas, aggregate dedup, report mapper)
• npm run test:web — 364 passed
• Per-task spec + code-quality review (persistence stale-closure safety + dual-key double-count independently verified)
• SSR content of both new pages verified in-browser (correct loaders/empty states; routes registered + reachable)
• Manual interactive click-through still recommended — the in-session Chrome E2E was blocked by a local dev-hydration/CSS flake (client JS didn't hydrate in the instrumented browser; documented gotcha), so the interactive CRUD/attach/report walk should be done once in a clean browser before/after merge.

🤖 Generated with Claude Code