docs: move release docs to release directory

Author: coreycb

docs/SUMMARY.md

@@ -45,11 +45,11 @@ generator, in this case, **mdbook**. It defines the structure and navigation of
   - [Troubleshooting]()
     - [Collecting Debug Logs](user-guide/troubleshooting/collecting-debug-logs.md)
     - [Find your app version](user-guide/troubleshooting/find-your-app-version.md)
-- [Release](ci/README.md)
-  - [Release Process](ci/RELEASE.md)
-  - [Release Automation](ci/AUTOMATION.md)
+- [Release]()
+  - [Release Process](release/RELEASE.md)
+  - [Release Automation](release/AUTOMATION.md)
   - [Developer Release Checklist](release/developer-checklist.md)
-  - [Manual Release (historical)](ci/HISTORICAL_RELEASE.md)
+  - [Manual Release (historical)](release/HISTORICAL_RELEASE.md)
 - [Security]()
   - [Threat Modeling Guide](security/threat-modeling-guide.md)
 

docs/ci/README.md

@@ -4,14 +4,14 @@ This checklist is for developers. It summarizes what you (as a contributor/featu
 - main → beta
 - beta → release
 
-For the full release-driver process (branch locks, announcements, publishing), see [Release → Release Process](../ci/RELEASE.md).
+For the full release-driver process (branch locks, announcements, publishing), see [Release → Release Process](../release/RELEASE.md).
 
 ## Ongoing (between merges)
 
 Do these as part of regular development:
 
 - Identify potential uplifts early
-  - Add risk and user impact notes to the issue/PR; ensure the fix lands on `main` and bakes on Daily first — see [Uplifts](../ci/RELEASE.md#uplifts) and [Uplift Criteria](../ci/RELEASE.md#uplift-criteria)
+  - Add risk and user impact notes to the issue/PR; ensure the fix lands on `main` and bakes on Daily first — see [Uplifts](../release/RELEASE.md#uplifts) and [Uplift Criteria](../release/RELEASE.md#uplift-criteria)
 - Strings and translations
   - Avoid late string changes; if unavoidable, keep them small, so translators can catch up
   - Prefer not changing localizable strings for uplifts
@@ -29,7 +29,7 @@ Do these as part of regular development:
 ## Before main → beta (developer responsibilities)
 
 > [!NOTE]
-> A one-week [Soft Freeze](../ci/RELEASE.md#soft-freeze) occurs before merging `main` into `beta`.
+> A one-week [Soft Freeze](../release/RELEASE.md#soft-freeze) occurs before merging `main` into `beta`.
 
 During soft freeze:
 - Avoid landing risky code changes
@@ -38,10 +38,10 @@ During soft freeze:
 Goal: Changes on `main` are safe to expose to a broader audience.
 
 - Feature flags
-  - Ensure flags match the [rules for beta](../ci/RELEASE.md#feature-flags)
+  - Ensure flags match the [rules for beta](../release/RELEASE.md#feature-flags)
     - New features are disabled by default unless explicitly approved for beta
     - Not-ready features must be disabled
-  - Prepare and merge a PR on `main` with necessary flag changes (before merge day)
+  - Prepare and merge a PR on `main` with necessary flag changes (before soft freeze starts)
 - Translations
   - Ensure translation updates needed for your features are merged to `main`
   - If no Weblate PR is pending, trigger one and help review it (fix conflicts if needed)
@@ -51,10 +51,10 @@ Goal: Changes on `main` are safe to expose to a broader audience.
 Goal: Changes on `beta` are safe for general availability.
 
 - Feature flags
-  - Verify flags align with [rules for release](../ci/RELEASE.md#feature-flags)
+  - Verify flags align with [rules for release](../release/RELEASE.md#feature-flags)
     - Features are disabled unless explicitly approved for release
     - Not-ready features remain disabled
-  - If changes are required, open a PR on `main` and request uplift to `beta` following the criteria in [Uplift Criteria](../ci/RELEASE.md#uplift-criteria)
+  - If changes are required, open a PR on `main` and request uplift to `beta` following the criteria in [Uplift Criteria](../release/RELEASE.md#uplift-criteria)
 - Translations
   - No new string changes at this stage; confirm your changes don’t introduce them
 - Stability checks you can influence
@@ -67,11 +67,11 @@ Goal: Changes on `beta` are safe for general availability.
 Paste the following snippet into your PR description to help reviewers and release drivers verify readiness for merge:
 
 ```markdown
-- [ ] Feature flags set according to target branch rules ([beta](../ci/RELEASE.md#feature-flags) / [release](../ci/RELEASE.md#feature-flags))
+- [ ] Feature flags set according to target branch rules ([beta](../release/RELEASE.md#feature-flags) / [release](../release/RELEASE.md#feature-flags))
 - [ ] Tests added/updated; CI green on affected modules
 - [ ] No new localizable strings (or justified and coordinated)
 - [ ] Translations accounted for (Weblate PR merged or not required)
-- [ ] Uplift label and risk/impact notes added if proposing uplift ([criteria](../ci/RELEASE.md#uplift-criteria))
+- [ ] Uplift template with risk/impact notes filled out if proposing uplift ([criteria](../release/RELEASE.md#uplift-criteria))
 ```
 
 ## After merges (what developers should verify)
@@ -81,5 +81,5 @@ Paste the following snippet into your PR description to help reviewers and relea
   - Be prepared to propose/prepare a hotfix via the uplift process if necessary
 
 > [!NOTE]
-> Merge-day coordination (branch locks, Matrix announcements, running scripts) is handled by release drivers. See [Merge Process](../ci/RELEASE.md#merge-process) for details.
+> Merge-day coordination (branch locks, Matrix announcements, running scripts) is handled by release drivers. See [Merge Process](../release/RELEASE.md#merge-process) for details.