docs(automation): say a packaged scheduled flow does not serve multiple tenants under isolated, and never hard-code an organization id into it (#20670)

Fixes #20619
Clause-②: no

## What changed

One file, `content/docs/automation/flows.mdx`, in "The acting
organization", directly after the "No fan-out" paragraph: +16 lines,
nothing removed, nothing else on the page touched.

- A paragraph saying that a **packaged** scheduled flow (one shipped
inside an app package that other organizations install) does not serve
multiple tenants under `isolated`. The once-per-organization declaration
needs an author who already knows the organization ids; a package
written before its tenants exist does not, and there is no key that
means "each organization that installs this package". Without a
declaration the flow stays unarmed: refused at bind, or, while
`OS_AUTOMATION_SCHEDULED_WORK_ENABLED` is off, listed as disabled by
deployment policy. The switch is linked to the subsection where the page
already names it.
- A ⛔ paragraph: never hard-code an organization id into a package flow
to get around this. The id would be a guess by an author who cannot know
who installs the package, and a wrong `organization_id` is worse than a
missing one.

The 17.5 release notes are not edited (release-owned). `content/docs`
ships in no package, so this diff needs no changeset; the
`skip-changeset` label goes on with the PR assignee.

## Ruling this implements

The maintainer's 「20619 A」, relayed by the director seat in the ruling
comment on #20619 (5890848676). The operative lines, verbatim:

> **Ruled: A.** Ruling G on #17396 (`5642381255`, addendum `5642795312`)
stands: package-authored scheduled work stays behind its deployment
switch, default OFF, off for multi-tenant kernels; under `isolated` a
`schedule` / `time_relative` flow declares one `config.organization` and
there is no fan-out.

> The docs say so plainly, beside `content/docs/automation/flows.mdx`'s
「No fan-out」 paragraph: a packaged scheduled flow does not serve
multiple tenants under `isolated`, and ⛔ an organization id is never
hard-coded into a package flow to get around it (the failure the key
exists to prevent).

## What the sentence rests on (measured on the branch base, 9b402db)

- The page already names the switch in "Does this deployment run
scheduled work at all?" and says it is off by default in every tenancy
posture and every kernel.
- `packages/triggers/trigger-schedule/src/schedule-trigger.ts`: under
`isolated` with the switch on, a time-triggered flow declares its
organization or is not armed, no fan-out, no organization chosen for it.
`packages/types/src/env.ts` holds the switch and the
disabled-by-deployment-policy reason the new text names.
- `content/docs/deployment/tenancy-modes.mdx`, `isolated` row, says the
same without the packaged qualifier: consistent, not edited.

## Verification

All of it is the full re-run at head `abc548399` (a container restart
cut the first pass).

- MDX compile of the edited page: OK (128616 bytes; the base version
compiles at 127671, so the check reads the file).
- Derived gates: re-derived against the real diff (merge base
9b402db), the same 40 commands as at dispatch. All 40 exit 0, exit
codes captured before any pipe. `dispatch-gates --ran`: 40 derived, 40
run, 0 NOT-MEASURED, every exit code recorded. Among them
`check:doc-anchors` (the new in-page link resolves; 392 links over 412
files), `check:doc-authoring`, `check:docs-transcript-drift`,
`check:docs-single-h1`, `check:nul-bytes`.
- Roster families printed outside the runnable list (58), run and listed
separately: 55 exit 0, 3 exit 2. Of the 55, 18 are checker-health only
(self-test), so they say nothing about this diff, and 1
(`check:console-injection`) exits 0 but prints that it skipped for lack
of a console build, which reads NOT MEASURED. That leaves 36
verdict-bearing greens.
- NOT MEASURED locally: `check-closing-target-claim.mjs`,
`check-partof-closing-keyword.mjs` (run afterwards against this body)
and `check-single-claim-paths.mjs` need a PR number and token (exit 2,
wiring); `check:console-injection` needs `pnpm objectui:build`, which
clones the sibling repo, outside this card's read scope.
- CI owns the rest: `pnpm lint`, the type-check lanes, Build Docs, Test
Core shards.

## Acceptance notes

- `main` advanced five commits since the base, one of them a docs change
to another section of this page; a merge probe against it is clean and
this diff stays the 16 added lines.
- The same section shows a literal example id for a deployment-authored
flow, above the new ⛔. The ⛔ is scoped to package flows and the ruling
asked for the paragraph and the ⛔ only, so the example is unchanged.
Noted, not filed.
- The end state, `config.organization: '*'` on a packaged flow, is
recorded on #20645, which stays open and is not touched here.

## Patch round 1 (the seat's append)

- The phrase `no key means "each organization that installs this
package"` could parse as "having no key means every installing
organization", which is the fan-out ruling A declines. At `14711581` it
reads `there is no key that means "each organization that installs this
package"`: three lines replaced by three, and nothing else on the page
changed. The seat corrected the quote under What changed in place.
- **At `14711581`:** `check:doc-anchors`, `check:doc-authoring`,
`check:docs-single-h1`, the frontmatter check and `check:nul-bytes` all
exit 0. The MDX compile passes. All 40 derived gates exit 0 (`--ran` 40
/ 40 / 0). `check:doc-authoring` was also measured against current
`main`'s baseline (the derivation flagged it moved): exit 0. The
Verification section above describes round one at `abc548399`.


---
_Generated by [Claude
Code](https://claude.ai/code/session_01XY5uCwTjZj7884yYtyur4H)_

---------

Co-authored-by: Claude <noreply@anthropic.com>

Author: objectstack-fleet[bot]

content/docs/automation/flows.mdx

@@ -2382,6 +2382,22 @@ never binds in the first place.
 **No fan-out.** A single flow belongs to one organization. A sweep wanted in
 several organizations is declared once per organization.
 
+That once-per-organization declaration needs an author who already knows the
+organization ids, and a package written before its tenants exist does not. So a
+**packaged** scheduled flow — one shipped inside an app package that other
+organizations install — does not serve multiple tenants under `isolated`: there
+is no key that means "each organization that installs this package", and without
+a declaration the flow stays unarmed — refused at bind as above, or, while the
+[deployment switch](#does-this-deployment-run-scheduled-work-at-all)
+(`OS_AUTOMATION_SCHEDULED_WORK_ENABLED`) is off, listed as disabled by
+deployment policy.
+
+⛔ Never hard-code an organization id into a package flow to get around this.
+The id would be a guess made by an author who cannot know who installs the
+package, and a wrong `organization_id` is worse than a missing one: it is
+silently authoritative to every run, notification, history row, report and
+export the flow touches.
+
 <Callout type="warn">
 The start node's `config` is an open record, so a near-miss spelling —
 `organizationId`, `organization_id`, `orgId`, `org_id`, `tenantId` — parses