Operator Actions in Another Organization

Goal: an operator viewing or acting for another org either can do the action in one step or is told up front what to switch — never a silent no-op, a raw 404/403 or a control that looks editable but isn't. - Add slots from a tenant node: preselect the node and declare the slot, or say "act as <org>"; never "unknown node '<uuid>'". - New session / New task (inline ▶ and "Open the full editor"): start in the target org in one action, keep the typed text and project, show the same Push-as dialog as the full editor; a started task appears in that org's feed. - Delete/Edit of another org's credential or account: offered only when allowed, else "Switch to <org>"; a refused delete keeps the dialog open with the reason; read-only switches look disabled. - New credential under an org filter asks which org owns it. - Answer tab on another org's question points to "Act as <org>". - Add connection for another org lists that org's clouds (`/providers?org_id`, operator only). - Brains row of another person's account shows whose it is, not "Provider unknown". - `commands.py` share-root and account-limit reads go through `_operator_node_in_another_org`; clone-owner 409 names operator declarers and the real fix. Out of scope: changing who may do what (authz stays). Done means: each item has a test (api or vitest); a dev walkthrough as operator over Org B hits no raw error (screenshots desktop + 390px).

Operator actions in another org now complete in one step or name the switch up front; all 8 items have API/vitest tests. Quick gate green; PR #6638 is queued to the merge lane. Dev walkthrough over Org B done at desktop and 390px with no raw errors. Follow-up draft #9051 filed. Memory: none applied.