docs: pair every StackBlitz button with a CodeSandbox alternative

The CodeSandboxButton component shipped in the initial docs commit but
was never actually used in any MDX page — leaving CodeSandbox-leaning
readers without an explicit 'open in CodeSandbox' CTA. Add the button
next to every StackBlitzButton across guide + 22 recipe pages (EN + RU),
plus the homepage hero (EN + RU), pointing at the same example path.

Author: awesomesk1ll

apps/docs/src/content/docs/guide/getting-started.mdx

@@ -6,12 +6,14 @@ description: "Install Triggery, write your first trigger, fire your first event
 import { Aside, TabItem, LinkCard, CardGrid } from '@astrojs/starlight/components';
 import FrameworkTabs from '~/components/FrameworkTabs.astro';
 import StackBlitzButton from '~/components/StackBlitzButton.astro';
+import CodeSandboxButton from '~/components/CodeSandboxButton.astro';
 
 import PackageManagers from '~/components/PackageManagers.astro';
 
 In five minutes you'll have a single file that declares a scenario ("when a new message arrives and the user has notifications on — show a toast"), and three small components that plug into it. None of the components know about each other.
 
 <StackBlitzButton path="examples/vite-react-counter" label="Skip ahead — open the counter example in StackBlitz" />
+<CodeSandboxButton path="examples/vite-react-counter" label="Skip ahead — open the counter example in CodeSandbox" />
 
 ## Prerequisites
 

apps/docs/src/content/docs/index.mdx

@@ -99,6 +99,7 @@ For SolidJS use `@triggery/solid`, for Vue 3 use `@triggery/vue` — the API is
 <LinkButton href="/guide/getting-started/" icon="right-arrow">Read the Getting Started guide</LinkButton>
 <LinkButton href="/recipes/react/notification-pipeline/" variant="minimal">See it in a real recipe</LinkButton>
 <LinkButton href="https://stackblitz.com/github/triggeryjs/triggery/tree/main/examples/vite-react-counter?file=README.md" variant="minimal" icon="external">Open in StackBlitz</LinkButton>
+<LinkButton href="https://codesandbox.io/p/github/triggeryjs/triggery/main/examples/vite-react-counter" variant="minimal" icon="external">Open in CodeSandbox</LinkButton>
 
 ## What people are saying
 

apps/docs/src/content/docs/recipes/react/analytics.mdx

@@ -7,10 +7,12 @@ sidebar:
 
 import { Aside, LinkCard, CardGrid, FileTree } from '@astrojs/starlight/components';
 import StackBlitzButton from '~/components/StackBlitzButton.astro';
+import CodeSandboxButton from '~/components/CodeSandboxButton.astro';
 
 The analytics anti-pattern: every button and every form imports a `track(...)` helper, which imports the Segment SDK, which imports Amplitude, which is conditional on a feature flag — and the moment you want to swap providers, half your codebase changes. Triggery flips it: components fire a generic `ui:event`, a single trigger routes it to the right destination, and swapping providers is a one-file change.
 
 <StackBlitzButton path="examples/vite-react-analytics" label="Open in StackBlitz" />
+<CodeSandboxButton path="examples/vite-react-analytics" label="Open in CodeSandbox" />
 
 ## Scenario
 

apps/docs/src/content/docs/recipes/react/auth-reactions.mdx

@@ -7,10 +7,12 @@ sidebar:
 
 import { Aside, LinkCard, CardGrid, FileTree } from '@astrojs/starlight/components';
 import StackBlitzButton from '~/components/StackBlitzButton.astro';
+import CodeSandboxButton from '~/components/CodeSandboxButton.astro';
 
 Auth events are an architectural mess in every app: the access token expired *while the user was halfway through editing a form*, or a permission was revoked *while they have a privileged screen open*. Without a coordinator, every form and every screen has to subscribe to "auth events" and decide for itself. With Triggery, *the trigger* decides — features just register their state and their handlers.
 
 <StackBlitzButton path="examples/vite-react-auth-reactions" label="Open in StackBlitz" />
+<CodeSandboxButton path="examples/vite-react-auth-reactions" label="Open in CodeSandbox" />
 
 ## Scenario
 

apps/docs/src/content/docs/recipes/react/chat-mentions.mdx

@@ -7,10 +7,12 @@ sidebar:
 
 import { Aside, LinkCard, CardGrid, FileTree } from '@astrojs/starlight/components';
 import StackBlitzButton from '~/components/StackBlitzButton.astro';
+import CodeSandboxButton from '~/components/CodeSandboxButton.astro';
 
 A common product pattern: when the user is @-mentioned in chat, optionally relay the mention to an outbound integration (Slack, Discord, a webhook URL), then react to whether the relay succeeded — and let the user retry or disable the integration without writing it again. Triggery handles the *chain* of async work cleanly: one event in, one trigger drives the whole pipeline, side effects stay inside the components that own them.
 
 <StackBlitzButton path="examples/vite-react-chat-mentions" label="Open in StackBlitz" />
+<CodeSandboxButton path="examples/vite-react-chat-mentions" label="Open in CodeSandbox" />
 
 ## Scenario
 

apps/docs/src/content/docs/recipes/react/counter.mdx

@@ -7,10 +7,12 @@ sidebar:
 
 import { LinkCard, CardGrid } from '@astrojs/starlight/components';
 import StackBlitzButton from '~/components/StackBlitzButton.astro';
+import CodeSandboxButton from '~/components/CodeSandboxButton.astro';
 
 The "hello world" of Triggery. Two buttons fire an `increment`/`decrement` event; a counter component reacts via `useAction` and re-renders itself. Nothing more.
 
 <StackBlitzButton path="examples/vite-react-counter" label="Open in StackBlitz" />
+<CodeSandboxButton path="examples/vite-react-counter" label="Open in CodeSandbox" />
 
 ## The trigger
 

apps/docs/src/content/docs/recipes/react/debounced-search.mdx

@@ -7,10 +7,12 @@ sidebar:
 
 import { Aside, LinkCard, CardGrid, FileTree } from '@astrojs/starlight/components';
 import StackBlitzButton from '~/components/StackBlitzButton.astro';
+import CodeSandboxButton from '~/components/CodeSandboxButton.astro';
 
 The classic autocomplete: user types into a search field, the app fetches suggestions from an API, late responses don't overwrite newer ones, the network isn't hammered. Without Triggery this is a 40-line `useEffect` riddled with refs, race-condition bookkeeping, and an `AbortController` you carry around by hand. With Triggery the input fires one event per keystroke and the trigger handles concurrency, cancellation and debouncing declaratively.
 
 <StackBlitzButton path="examples/vite-react-debounced-search" label="Open in StackBlitz" />
+<CodeSandboxButton path="examples/vite-react-debounced-search" label="Open in CodeSandbox" />
 
 ## Scenario
 

apps/docs/src/content/docs/recipes/react/form-with-zod.mdx

@@ -7,10 +7,12 @@ sidebar:
 
 import { Aside, LinkCard, CardGrid, FileTree } from '@astrojs/starlight/components';
 import StackBlitzButton from '~/components/StackBlitzButton.astro';
+import CodeSandboxButton from '~/components/CodeSandboxButton.astro';
 
 A trigger's event payload is typed at compile time, but runtime data — form submissions, URL params, WebSocket frames — comes in unstructured. Triggery's recommended pattern: validate **at the producer's boundary**, fire only what passes. The trigger handler then sees a fully typed, runtime-checked payload. This recipe shows the idiom and packages it as a small `useValidatedEvent` helper so every producer in the app is a one-liner.
 
 <StackBlitzButton path="examples/vite-react-form-zod" label="Open in StackBlitz" />
+<CodeSandboxButton path="examples/vite-react-form-zod" label="Open in CodeSandbox" />
 
 ## Scenario
 

apps/docs/src/content/docs/recipes/react/modal-stack.mdx

@@ -7,10 +7,12 @@ sidebar:
 
 import { Aside, LinkCard, CardGrid, FileTree } from '@astrojs/starlight/components';
 import StackBlitzButton from '~/components/StackBlitzButton.astro';
+import CodeSandboxButton from '~/components/CodeSandboxButton.astro';
 
 Every non-trivial app eventually grows a modal mess: "Confirm delete" opens "Resolve conflict" opens "Reauthenticate" — all from different features, none of them wanting to know about each other. Triggery turns this into a one-liner per feature: fire `modal:open`, fire `modal:close`, listen if you care. Per-route stacks come for free with `<TriggerScope>`.
 
 <StackBlitzButton path="examples/vite-react-modal-stack" label="Open in StackBlitz" />
+<CodeSandboxButton path="examples/vite-react-modal-stack" label="Open in CodeSandbox" />
 
 ## Scenario
 

apps/docs/src/content/docs/recipes/react/notification-pipeline.mdx

@@ -7,13 +7,15 @@ sidebar:
 
 import { Aside, LinkCard, CardGrid, TabItem, Steps, FileTree } from '@astrojs/starlight/components';
 import StackBlitzButton from '~/components/StackBlitzButton.astro';
+import CodeSandboxButton from '~/components/CodeSandboxButton.astro';
 import PackageManagers from '~/components/PackageManagers.astro';
 
 The canonical scenario: a new chat message arrives and three side effects happen *in different components*, gated by *user state owned by yet another component*. None of them know about each other. Reading the trigger file tells a product manager exactly what happens, and reading the components tells nobody anything but their own job.
 
 This is the scenario the rest of the docs use to compare against `useEffect`/saga/listener alternatives.
 
 <StackBlitzButton path="examples/vite-react-notifications" label="Open the full example in StackBlitz" />
+<CodeSandboxButton path="examples/vite-react-notifications" label="Open the full example in CodeSandbox" />
 
 ## Scenario