docs(flows): scope the null-guard callout to TOTAL bindings (#8975)

The flow `condition` callout closed with "Guard emptiness with
`record.x != null` / `isBlank(record.x)`, same as everywhere else CEL runs".
The callout is correct about flows — it explicitly scopes itself to the total
binding — but that trailing generalization is exactly what the rest of this PR
makes false: on the sparse action `visible`/`disabled` face, `!= null` alone
faults with `No such key` on a column the list row never projected.

Amended to "the same rule every other TOTAL binding carries", plus one
paragraph naming the single sparse face and its conjunction guard, so an author
reading this page cannot carry the flows rule across to a face it breaks on.
The flows rule itself is unchanged and still holds here.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NTKPDRoynY8i3HmdSFUxFj

Author: claude

content/docs/automation/flows.mdx

@@ -1259,9 +1259,17 @@ evaluate cleanly instead of aborting with `No such key`. `has(record.x)` is
 therefore uniformly `true` for a *declared* field the moment it's present at
 all — including when its value is `null` — so it answers "is `x` declared on
 this object", never "does `x` have a value". Guard emptiness with
-`record.x != null` / `isBlank(record.x)`, same as everywhere else CEL runs
-(see the [`has()` gotcha](/docs/data-modeling/formulas#cel-primer) above).
-`has()` still earns its keep against a genuinely *undeclared* key.
+`record.x != null` / `isBlank(record.x)` — the same rule every other ***total***
+binding carries (see the [`has()` gotcha](/docs/data-modeling/formulas#cel-primer)
+above). `has()` still earns its keep against a genuinely *undeclared* key.
+
+⚠️ **That scoping is load-bearing, not pedantry.** One binding on the platform
+is *sparse* by decision: an [action](/docs/ui/actions) `visible` / `disabled`
+predicate is evaluated against whatever record the client already fetched —
+on a list row, only the columns that view actually projected. There
+`record.x != null` **is itself a fault** on an absent key, and the guard is the
+conjunction `has(record.x) && record.x != null`. Flows are not that face; the
+rule above holds here. Just don't carry it across to one where it doesn't.
 </Callout>
 
 ## Run a flow via API