docs: add a review agenda and config compatibility rules

Reviewing the project used to mean re-stating what to look at every time.
docs/REVIEW.md now holds that agenda once — nine areas, each anchored to this
codebase — and both entry points point at it rather than copying it: the
/review-project command in .claude/commands, and a section in CLAUDE.md so a
plain-language review request lands in the same place.

STANDARDS.md gains a "Config file compatibility" section. The project has
applied the same rule three times (Theme, JobListView, TimeoutSeconds) without
ever writing it down: a new Config field is omitempty and its zero value means
the previous behavior, a meaningful zero is never backfilled on load, and an
unrecognised enum value reads as the default through one shared helper. With no
migration step and hand-editable files, that is what keeps older configs working.

Also removes docs/PLAN-compact-job-list.md, implemented in edabc57 — everything
but the version bump, which now waits for the release along with the rest of
the Unreleased section. .claude/settings.local.json is ignored so the shared
command can be tracked without per-developer permissions.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.claude/commands/review-project.md

@@ -0,0 +1,26 @@
+---
+description: Review the project as a whole against the agenda in docs/REVIEW.md
+---
+
+Perform a whole-project review of GoSentry.
+
+Read [docs/REVIEW.md](../../docs/REVIEW.md) first — it is the agenda, and its
+nine sections are the areas to cover. Read [docs/STANDARDS.md](../../docs/STANDARDS.md)
+and [docs/ARCHITECTURE.md](../../docs/ARCHITECTURE.md) for the rules and
+contracts the code is checked against.
+
+$ARGUMENTS narrows the review when given — a package path, a file, or the name
+of an agenda section. With no arguments, sweep the whole `src/` tree.
+
+Rules for the report:
+
+- Anything listed under "Intentional behavior" in STANDARDS.md is not a finding.
+  If you believe such an entry is now wrong, say so explicitly as a challenge to
+  the decision rather than reporting it as a bug.
+- Verify before reporting. Read the surrounding code and, where cheap, confirm
+  the behavior with a test rather than reasoning about it alone.
+- Group findings by agenda section, most severe first, each with the file and
+  line and what would actually go wrong.
+- Report honestly that a section is clean rather than inventing something for it.
+- Do not fix anything during the review. Report first; apply fixes only when
+  asked, following "What happens to the findings" in REVIEW.md.