docs(project): refresh baseline verification artifacts

Check in the PM product requirements, refreshed QA acceptance evidence, shared execution split plans, and current-phase status notes so the repo matches the current delivery baseline.

Co-Authored-By: Paperclip <noreply@paperclip.ing>

plans/2026-03-31-add-key-preview-containment.md

@@ -0,0 +1,41 @@
+# Add Key Preview Containment
+
+Date: 2026-03-31
+Owner: Senior Frontend Engineer
+Related items:
+
+- `plans/2026-03-31-add-key-phase-boundary.md`
+- `docs/redis-gui-v1-product-requirements.md`
+- `docs/frontend-workspace-baseline.md`
+- `docs/qa/acceptance-matrix.md`
+
+## Goal
+
+Keep the already-implemented `Add Key` surface visible without letting it read like approved `desktop-v1` scope.
+
+## Decision
+
+- Do not hide the flow in this worktree.
+- Use the PM-approved fallback containment path instead: visible `Preview` labeling in the key-browser header and inside the Add Key dialog.
+- Keep docs and QA wording aligned so the visible preview label and the acceptance boundary say the same thing.
+
+## Scope
+
+- add a visible preview label beside the `Add key` entry point
+- repeat the preview label inside the dialog header
+- make the dialog description explicit that Add Key stays outside current `desktop-v1` baseline acceptance
+- sync shared README and QA/frontend docs
+
+## Non-Goals
+
+- no Add Key contract change
+- no Add Key workflow expansion
+- no current-phase reclassification
+- no hide-or-gate implementation
+
+## Acceptance
+
+- operators can see from the shell that `Add Key` is preview inventory rather than baseline scope
+- docs do not describe the visible Add Key entry as approved `desktop-v1` acceptance
+- `pnpm --filter @redis-gui/desktop test` passes
+- `pnpm run desktop:build` passes