feat: resolve Review items via the API (PATCH + bulk) + a Refresh button

[AndrewDongminYoo]

Problem

The Review tab is the one stateful surface with no way to act on it from outside the WebView, and no way to re-sync once loaded:

• The API could read review items (GET .../reviews) but not resolve them.
• Unlike the Lint tab (which has a re-run), the Review tab never re-reads review.json after the initial load — an external change stays invisible until the project is reopened.

This matters for headless / scripted wiki maintenance: you can export the review queue but can't close items programmatically, and you can't see changes made outside the running app.

What this adds

1. Single-item update — PATCH /api/v1/projects/{id}/reviews/{reviewId}

PATCH .../reviews/review-3
{ "resolved": true, "action": "Skip" }

Partial update of one item. resolved defaults to true (the common case); pass false to reopen. action is an optional label. Mark-only — it deliberately does not replicate the WebView's resolve side effects (page creation, deep research, save-to-wiki). 404 on unknown id.

PATCH (rather than a POST .../resolve action path) is the REST-correct shape for a resource state change. It needed the server's method gate + CORS Allow-Methods opened to PATCH — verified tiny_http 0.12 parses PATCH into Method::Patch so the route actually fires.

2. Bulk resolve — POST /api/v1/projects/{id}/reviews/resolve

POST .../reviews/resolve
{ "ids": ["review-1", "review-2"], "action": "Skip" }
→ 200 { "resolved": [...], "notFound": [...], "count": N }

Partial success is the norm for bulk, so this returns 200 with resolved / notFound rather than 404. Reads review.json once and writes once (no per-id race window from looping the single-item path).

Both write paths edit the raw review.json array rather than the sanitizing reader used by GET, so fields the sanitizer drops (e.g. internalSecret) survive write-back. Covered by tests.

3. Refresh button on the Review tab

Reloads review.json from disk. The missing counterpart to lint's re-run, and the intended way an external resolve surfaces: API writes disk → user hits Refresh → store reloads. No bespoke event channel for v1.

Tests

Rust unit tests: PATCH resolve + unsanitized-field preservation, reopen via resolved:false, unknown id, missing file; bulk resolve + notFound reporting, missing file. (Also hardened the shared test_project_dir() helper with an atomic sequence — nanosecond-only temp dirs collided under parallel cargo test.)

Docs / i18n

Endpoints list in Settings → API Server, README.md, and en/zh locale notes updated. Other locale READMEs left to the maintainer.

Possible follow-ups (not in this PR)

Live auto-reload via a Rust app.emit → WebView listener if manual refresh proves insufficient; an mcp-server bulk-resolve tool mirroring the existing llm_wiki_reviews tool.