docs(explore): note Explore read permission and third-party cookie limits

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/docs/using-superset/embedding.mdx

@@ -139,6 +139,27 @@ The following URL parameters can be passed through the `urlParams` option in `da
 
 ---
 
+## Embedding a Single Chart
+
+Individual charts can also be embedded standalone, outside of a dashboard, using a chart permalink. From Explore, generate a permalink for the chart, then append URL parameters to it:
+
+```
+/explore/p/<permalink-key>/?standalone=1&show_download=1
+```
+
+| Parameter       | Values   | Effect                                                                     |
+| --------------- | -------- | -------------------------------------------------------------------------- |
+| `standalone`    | `0`, `1` | `0`: normal Explore view; `1`: hide the Explore header and controls        |
+| `show_download` | `0`, `1` | Show a compact download control (CSV, JSON, Excel) on the standalone chart |
+
+`show_download` is opt-in and has no effect outside of `standalone=1`. The download control still respects the viewer's export permissions — it's hidden for users who lack them even when the parameter is set. With the `GRANULAR_EXPORT_CONTROLS` feature flag enabled, this requires the `can_export_data` permission on `Superset`; otherwise it falls back to `can_csv` on `Superset`.
+
+Explore's **Embed Code** button on a chart also generates one of these permalink URLs wrapped in an `<iframe>`, giving you a session-authenticated iframe embed. That's a separate flow from dashboard embedding above: it doesn't go through `@superset-ui/embedded-sdk`, guest tokens, or the `dashboardUiConfig` options — the viewer needs an existing Superset session with the `can read on Explore` permission, in addition to access to the chart itself. Viewing the same chart on a dashboard doesn't require that permission, so a role scoped only for dashboard viewing gets an access denial on this URL.
+
+One caveat when the host page lives on a different site than Superset: the default `SESSION_COOKIE_SAMESITE = "Lax"` setting keeps the session cookie out of cross-site iframe requests, so the viewer lands on the login page instead of the chart. Serving both from the same site avoids this; otherwise set `SESSION_COOKIE_SAMESITE = "None"` together with `SESSION_COOKIE_SECURE = True` and allow the host origin in your `TALISMAN_CONFIG` `frame-ancestors`. Even with that configuration, browsers that block third-party cookies by default (including Safari) can still redirect the viewer to the login page. For those cases, host the iframe on the same site as Superset, or use the dashboard embedding SDK's guest-token flow above instead.
+
+---
+
 ## Security Notes
 
 - **Guest tokens expire** — their lifetime is controlled by the `GUEST_TOKEN_JWT_EXP_SECONDS` config (default: 5 minutes). Refresh tokens before they expire using a token refresh mechanism in your host app.