ReviewSetupDialog never shows on a truly fresh profile

Found during screenshot verification of #1462, pre-existing on main (packages/review-editor/utils/reviewSetup.ts is untouched by that branch).

On a genuinely fresh browser profile, the first-run dialog chain runs guide intro, look and feel, then skips straight past ReviewSetupDialog to the Edit Mode announcement. Verified with a step-by-step dialog dump during real chain traversal.

Mechanism: configStore.ensureLoaded() seeds every settings-registry default into the cookie jar on first settings access, including reviewPanelView. When initializeReviewSetup() runs afterward, it finds a reviewPanelView cookie, treats it as a persisted reviewer choice, marks review-setup-seen, and returns false. The dialog that CLAUDE.md documents as "first-run shows ReviewSetupDialog" is therefore unreachable for new users; it only appears via the header menu reopen path.

Impact: new reviewers never get the one-time panel/diff-default setup choice. Low severity since the defaults are sensible and the dialog is reopenable, but the documented first-run behavior does not happen.

Fix shape to evaluate: initializeReviewSetup should distinguish a registry-seeded default from a user-persisted choice (the registry seeding writes the built-in default; a marker or ordering change would disambiguate), or run before ensureLoaded seeds that key, mirroring how the WebMCP preference deliberately stayed out of the registry to avoid exactly this seeding side effect.

Start in packages/review-editor/utils/reviewSetup.ts, tracing initializeReviewSetup alongside configStore.ensureLoaded and the fresh-profile dialog chain. Compare the registry-seeded reviewPanelView with a user-persisted choice, then verify through real chain traversal that a fresh profile shows ReviewSetupDialog while an existing choice still skips it.

Written by the indexing model from the issue text.