Remove redundant Mermaid theme initialization tags across BFF documentation and improve content structure for clarity.

Author: khalidabuhakmeh

astro/src/content/docs/bff/architecture/index.mdx

@@ -26,7 +26,6 @@ If you haven't yet decided whether to use BFF, start with the [overview](/bff/)
 The following diagram shows how the BFF protects browser-based applications:
 
 ```mermaid
-%%{ init: { 'theme': 'default' } }%%
 flowchart TD
     subgraph Browser
         SPA["Browser-Based Application"]
@@ -131,7 +130,6 @@ Both are supported, but have different integration patterns:
 ## Trust Boundaries
 
 ```mermaid
-%%{ init: { 'theme': 'default' } }%%
 flowchart TD
     subgraph Browser["Browser (untrusted)"]
         B1["Holds session cookie only<br/>(HttpOnly, Secure, SameSite)"]

astro/src/content/docs/bff/architecture/ui-hosting.md

@@ -31,7 +31,6 @@ headers. This makes the BFF and the front-end application a single deployable un
 what that would look like:
 
 ```mermaid
-%%{ init: { 'theme': 'default' } }%%
 flowchart LR
     subgraph Browser["Browser: https://application.url"]
         app["app"]
@@ -80,7 +79,6 @@ and the BFF, and you might want your static UI assets hosted on a CDN. Below is
 look like:
 
 ```mermaid
-%%{ init: { 'theme': 'default' } }%%
 flowchart LR
     subgraph Browser["Browser: https://application.url"]
         app["app"]
@@ -131,7 +129,6 @@ cookie will be sent from the frontend to the BFF automatically, and third party
 attribute won't present any problems. The following diagram shows how that would work:
 
 ```mermaid
-%%{ init: { 'theme': 'default' } }%%
 flowchart LR
     subgraph Browser["Browser: https://application.url"]
         app["app"]

astro/src/content/docs/bff/fundamentals/apis/index.md

@@ -18,7 +18,6 @@ A frontend application using the BFF pattern can call two types of APIs: embedde
 ## Choosing an API Approach
 
 ```mermaid
-%%{ init: { 'theme': 'neutral' } }%%
 flowchart TD
     Q1{"Is the API only used<br/>by this frontend?"}
     Q2{"Do you need load balancing,<br/>service discovery, or<br/>complex routing/transforms?"}

astro/src/content/docs/bff/fundamentals/blazor/data-access.mdx

@@ -13,7 +13,6 @@ Depending on your Blazor rendering mode, you need different strategies for acces
 ## Overview
 
 ```mermaid
-%%{ init: { 'theme': 'neutral' } }%%
 flowchart LR
     WASM["Blazor WASM Component<br/>(browser)"]
     Server["BFF Host<br/>(server)"]
@@ -132,7 +131,6 @@ builder.Services.AddTransient(sp =>
 The diagram below shows the full flow:
 
 ```mermaid
-%%{ init: { 'theme': 'neutral' } }%%
 sequenceDiagram
     participant WASM as Blazor WASM
     participant BFF as BFF Host

astro/src/content/docs/bff/fundamentals/blazor/index.md

@@ -22,7 +22,6 @@ The Duende BFF Security Framework addresses these challenges by keeping access t
 A BFF-backed Blazor app has three elements: the **backend** (server-side logic and APIs), the **frontend** (the Blazor application), and the **client** (the browser). The BFF host acts as the combined backend and frontend host:
 
 ```mermaid
-%%{ init: { 'theme': 'default' } }%%
 flowchart LR
     Client[Client / Browser]
     subgraph BFF Host

astro/src/content/docs/bff/fundamentals/deployment.mdx

@@ -32,6 +32,8 @@ builder.Services.AddDataProtection()
 
 :::caution[Do not use in-memory keys in production]
 The default in-memory key ring is regenerated on every restart. Any existing sessions are invalidated when the process restarts or when traffic is routed to a new instance.
+
+See also: [Data Protection](/general/data-protection/)
 :::
 
 ### Server-Side Sessions (Recommended for Multi-Instance)

astro/src/content/docs/bff/fundamentals/session/index.mdx

@@ -21,7 +21,6 @@ Authentication in a BFF application flows through several layers. Understanding
 ## How Sessions Work
 
 ```mermaid
-%%{ init: { 'theme': 'neutral' } }%%
 sequenceDiagram
     participant Browser
     participant BFF