docs(objectql): say what the atomicity plan's twin test changes, as measured

On the showcase the plan still reaches the federated object through its
injected owning_business_unit_id at depth 1, so its verdict for an
organization delete stays cross-datasource. The comments and the changeset
now claim only that the plan keeps the scan's participant test.

Claude-Session: https://claude.ai/code/session_017ErfyP2Rx7XWHJA27QjyUi
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

.changeset/21910-cascade-federated-tenant-anchor.md

@@ -7,5 +7,5 @@ Deleting an organization no longer fails with a 500 on a deployment that has a f
 Clause-②: no
 
 - **What was wrong.** The registry injects `organization_id` into every object, federated ones included, and the platform provisions no storage for a federated object. The cascade's dependents probe filtered the remote table on that column, the SQL driver refused the unknown column (`INVALID_FILTER`), and the probe's failure propagated, so the delete failed. The showcase, with its federated fixture provisioned, answered every organization delete with 500.
-- **What changed.** The cascade scan skips a federated object's injected tenant anchor. It asks the same `isFederatedObject` predicate as the driver-option builder and the related-record read, plus the injected-column provenance marker, so an `organization_id` the author declared on a federated object is still probed. The cascade's atomicity plan asks the same question, so an organization delete on such a deployment now runs as one transaction instead of being reported as a cross-datasource cascade.
+- **What changed.** The cascade scan skips a federated object's injected tenant anchor. It asks the same `isFederatedObject` predicate as the driver-option builder and the related-record read, plus the injected-column provenance marker, so an `organization_id` the author declared on a federated object is still probed. The cascade's atomicity plan asks the same question, so it keeps counting exactly the relations the scan probes.
 - **What did not change.** Any lookup an author declares on a federated object is still probed, and a probe that cannot run still fails the delete. Only a missing child table is passed over as having no dependents.

packages/objectql/src/engine.ts

@@ -15858,11 +15858,10 @@ export class ObjectQL implements IObjectQLEngine {
           try { resolvedRef = this.resolveObjectName(ref); } catch { resolvedRef = undefined; }
           if (ref !== name && resolvedRef !== name) continue;
           // [#21910] The scan skips a federated object's injected tenant
-          // anchor, so this walk does too, and the participant set stays the
-          // scan's. Counting it read every organization delete on a deployment
-          // with a federated object bound as cross-datasource (`'split'`): the
-          // cascade ran unwrapped, and the warning named a datasource the
-          // cascade never touches.
+          // anchor, so this walk does too: the participant test stays the
+          // scan's own, as the comment above requires. A federated object this
+          // walk still reaches through any other relation keeps the verdict
+          // `'split'`, because the scan probes that relation.
           if (isFederatedInjectedTenantAnchor(child, fieldName)) continue;
           out.push(childName);
           break;

packages/objectql/src/federated-object.ts

@@ -51,8 +51,8 @@ export function isFederatedObject(schema: unknown): boolean {
  * - `ObjectQL.cascadeDeleteRelations` does not probe the remote table on it
  *   (the probe was refused as an unknown column, and every organization
  *   delete answered 500);
- * - `ObjectQL.planCascadeAtomicity` does not count the federated object as a
- *   participant on another datasource.
+ * - `ObjectQL.planCascadeAtomicity` does not count that column as making the
+ *   federated object a participant, so its participant test stays the scan's.
  *
  * Three conjuncts, and each one is the narrowing:
  *