fix(docs): repair broken anchors and missing images (#2171)

Two links pointed at headings that do not exist (per-stack alert rules and
the Fleet Sync control anchor); both now use the real heading ids.

The Overview page and the environment guardrails tutorial referenced two
screenshots that are not in the docs. The Overview page reuses the Security
screenshot already shipped on the introduction page, and the tutorial drops
the single frame, since the step text already quotes the message.

The Resources page named its Rollback tab but never described it; it now has
a short section that links to the full explanation. A stray file left over
from the organization migration is deleted.

docs/features/atomic-deployments.mdx

@@ -67,7 +67,7 @@ Check this panel in the dossier before rolling back a stack that has been runnin
     The entry is also hidden for users who lack the `stack:deploy` permission. Ask an admin to grant `stack:deploy` through **Settings · Access** if the entry does not appear.
   </Accordion>
   <Accordion title="The deploy succeeded but a service crashed seconds later">
-    The health probe is a 3-second window after `docker compose up -d` returns. Crashes after that window are out of scope for atomic rollback, because Sencho cannot tell a late exit apart from a normal restart. The [health gate](/features/health-gated-updates) covers exactly this period: it observes the stack for a configurable window after the update, records a verdict on the stack timeline, and offers a manual rollback when containers do not stay healthy. The gate does not auto-compensate. For ongoing health beyond that, use [Auto-Heal Policies](/features/auto-heal-policies) to restart unhealthy containers automatically and [per-stack alert rules](/features/alerts-notifications#per-stack-alert-rules) to page you when a container exits unexpectedly.
+    The health probe is a 3-second window after `docker compose up -d` returns. Crashes after that window are out of scope for atomic rollback, because Sencho cannot tell a late exit apart from a normal restart. The [health gate](/features/health-gated-updates) covers exactly this period: it observes the stack for a configurable window after the update, records a verdict on the stack timeline, and offers a manual rollback when containers do not stay healthy. The gate does not auto-compensate. For ongoing health beyond that, use [Auto-Heal Policies](/features/auto-heal-policies) to restart unhealthy containers automatically and [per-stack alert rules](/features/alerts-notifications#stack-alert-rules) to page you when a container exits unexpectedly.
   </Accordion>
   <Accordion title="The deploy progress modal showed 'Rollback failed. Manual intervention may be required'">
     This message means the auto-rollback attempted to restore from the recovery generation and re-deploy, but the restore step or the re-deploy itself errored out. The generation remains listed under **Resources → Rollback**. To recover:

docs/features/cve-suppressions.mdx

@@ -139,7 +139,7 @@ You can also export the full set of triage decisions as an **OpenVEX** document
     - **Expired rule.** If **Expires in** was set, the suppression stops applying after the deadline. The panel shows an `expired` badge on that row; remove it and create a fresh rule.
   </Accordion>
   <Accordion title="A replica refuses pushes from my control with 'control identity mismatch'">
-    Each replica anchors to the first control fingerprint it receives. If a different control later tries to push (for example, after rebuilding the control from a snapshot or migrating it to a new server), the replica rejects the push until it is reanchored. The reanchor procedure (admin API call on the replica) is documented in [Fleet Sync](/features/fleet-sync#control-anchor); the next push from any control after a reanchor becomes the new anchor.
+    Each replica anchors to the first control fingerprint it receives. If a different control later tries to push (for example, after rebuilding the control from a snapshot or migrating it to a new server), the replica rejects the push until it is reanchored. The reanchor procedure (admin API call on the replica) is documented in [Fleet Sync](/features/fleet-sync#anchor-and-re-anchor); the next push from any control after a reanchor becomes the new anchor.
   </Accordion>
   <Accordion title="My suppression list is large and the fleet sync warns about truncation">
     The fleet sync wire protocol caps a single push at 5,000 rows so a misconfigured control cannot wedge a replica with an unbounded payload. If your local list exceeds that cap, the warning appears in the control logs and only the first 5,000 rows are pushed. Trim expired or unused entries from the suppressions panel, or split scopes across distinct rules, so each remains meaningful before relying on fleet replication for the full set.

docs/features/overview.mdx

@@ -219,7 +219,7 @@ Open an interactive terminal on the host OS directly in the browser with full xt
 ## Security and access
 
 <Frame>
-  <img src="/images/overview/security-overview.png" alt="The Security page: the 'Action needed' masthead with critical and high CVE counts and last scan time, the tab strip (Overview, Images, Compose risks, Secrets, Policies, Suppressions, History, Scanner setup), the actionable findings summary listing fixable CVEs, detected secrets, and exposed images, and the 30-day risk trend chart." />
+  <img src="/images/introduction/security-overview.png" alt="Sencho Security view with the posture masthead, action summary, review queue, risk trend chart, and the tab strip" />
 </Frame>
 
 ### Security

docs/features/resources.mdx

@@ -147,6 +147,10 @@ The toolbar above the list provides a **Select all** checkbox and a destructive
 
 When no external containers are detected, the tab shows a success state with the message "No external containers" and the subline "All running containers are managed by Sencho."
 
+### Rollback
+
+Lists the recovery generations the node is holding, with a search box, a **Current** or **Superseded** filter, and sortable columns. An admin can release a generation's protection early from a row. [Automatic rollback images](/features/health-gated-updates#automatic-rollback-images) explains what each generation holds, how long it is kept, and what releasing costs.
+
 ## Troubleshooting
 
 <AccordionGroup>

docs/tutorials/configure-environment-guardrails.mdx

@@ -62,9 +62,6 @@ This tutorial covers one guardrail: **Block deploy on missing required env vars*
   <Step title="Watch Save & Deploy block with the exact guardrail message">
     Select **Save & Deploy** and this time keep **Save & Deploy** in the dropdown (not **Save Only**). The operation fails immediately, before any container changes, with **Deploy blocked: required environment variable DB_PASSWORD is missing. Define it in a .env or env_file, then deploy again.** The full message appears in the notification bell in the top bar.
 
-    <Frame>
-      <img src="/images/tutorials/configure-environment-guardrails/save-deploy-blocked-notification.png" alt="Notifications panel showing 'Deploy blocked: required environment variable DB_PASSWORD is missing. Define it in a .env or env_file, then deploy again.' from a Save & Deploy operation." />
-    </Frame>
     This demonstrates the fix: the guardrail message now properly appears when using **Save & Deploy**, matching the exact message shown when using **Update**. **Save & Pull Images** is covered by the same guardrail and refuses the same way, naming that action in the last sentence instead.
   </Step>
   <Step title="Update the stack and watch the guardrail fire">