docs(data-drains): describe the resolved feature, not the bare flag (#7475)

* docs(data-drains): describe the resolved feature, not the bare flag

Two things were wrong in the self-hosted flag paragraph.

The first sentence attributed the page and the endpoints to
`DATA_DRAINS_ENABLED` alone, which the next sentence then contradicted.
`enterpriseFeatureEnabled` resolves `explicit ?? (ENTERPRISE_ENABLED || legacy
default)`, and the legacy default for data drains is `false` — so the feature is
on with the variable unset whenever `ENTERPRISE_ENABLED` is set, and an explicit
`false` always wins. The paragraph now leads with that resolution.

The rationale given for the public twin was also wrong. Inside a workspace
`WorkspaceHostProvider` seeds the deployment shape from the server-resolved host
context, `useDeploymentShape()` returns that seeded value, and the settings
sidebar gates `data-drains` on `features.dataDrains` from it — so the page
follows the server regardless of the twin, and "set it so the browser matches
the server" misdescribed what the browser reads. The twin still backs
`browserFallbackShape()` where nothing has seeded the shape, and it is what
`sim-setup doctor` compares, so the advice to set it stands with the real reason.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* docs(data-drains): say the master switch must be true, not merely set

`isEnterpriseEnabled` is `isTruthy(env.ENTERPRISE_ENABLED)`, so
`ENTERPRISE_ENABLED=false` is set and still resolves off. "Is set" would have
implied an unset `DATA_DRAINS_ENABLED` turns drains on there.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: waleedlatif1

apps/docs/content/docs/platform/enterprise/data-drains.mdx

@@ -237,7 +237,9 @@ DATA_DRAINS_ENABLED=true
 NEXT_PUBLIC_DATA_DRAINS_ENABLED=true
 ```
 
-`DATA_DRAINS_ENABLED` shows the **Settings → Organization → Data drains** page and gates the server-side mutating endpoints and the cron dispatcher. When the feature resolves off on a self-hosted deployment — neither it nor `ENTERPRISE_ENABLED` is set, or it is set to `false` — the page is hidden, drain create/update/delete/run requests return `404`, and the dispatcher is a no-op. Set `NEXT_PUBLIC_DATA_DRAINS_ENABLED` to the same value so the browser's configuration matches the server's; on a Compose install or source checkout, `npx sim-setup doctor` reports the pair disagreeing.
+On a self-hosted deployment the feature resolves on when `DATA_DRAINS_ENABLED` is `true`, or when it is unset and `ENTERPRISE_ENABLED` is `true`. An explicit `DATA_DRAINS_ENABLED=false` wins over the master switch. That resolved value — not the bare variable — gates the **Settings → Organization → Data drains** page, the server-side mutating endpoints, and the cron dispatcher. When it resolves off the page is hidden, drain create/update/delete/run requests return `404`, and the dispatcher is a no-op.
+
+Inside a workspace the browser reads that resolved value from the server, so the page follows the server whether or not `NEXT_PUBLIC_DATA_DRAINS_ENABLED` is set. Set it to the same value anyway: it backs the client fallback on surfaces rendered outside a workspace, and on a Compose install or source checkout `npx sim-setup doctor` reports the pair disagreeing.
 
 ### Scheduling the dispatcher