feat(organizations): support many independent organizations per process

[vieiralucas]

Summary

Closes #2543 (second half; the first was #2546).

Organizations state was a process-wide Option<OrganizationState> — at most one organization could ever exist. CreateOrganization rejected on "an organization exists" rather than "the caller is already in one":

if guard.is_some() {
    return Err(... "AlreadyInOrganizationException" ...);
}

So once any account created an organization, every other account in the process was permanently locked out of creating its own. The reporter's script vends two management accounts and expects two independent organizations with two child accounts each; the second CreateOrganization failed purely because the first organization existed.

The state becomes an OrganizationsRegistry keyed by organization id. An account still belongs to at most one organization, which is what makes "the caller's organization" well defined, so almost every handler now resolves through org_of_account instead of reaching for the singleton. Organizations never see each other: a caller in none gets the same AWSOrganizationsNotInUseException as a process with no organizations at all.

Behavior

• CreateOrganization rejects only when the calling account is already a member — same for the CloudFormation AWS::Organizations::Organization provisioner. DeleteOrganization removes exactly the caller's organization instead of clearing the world.
• An account can be in one organization only. Inviting an account another organization already holds is HandshakeConstraintViolationException / Reason=ALREADY_IN_AN_ORGANIZATION, re-checked when the handshake is accepted — the target may have joined elsewhere while the invitation sat open.
• Handshakes resolve by id across organizations, because the account answering an invitation is not yet a member of the inviting one. ListHandshakesForAccount likewise spans organizations. DescribeHandshake is limited to the handshake's two parties.
• SCP ceilings and AssumeRoot resolve the principal's/caller's own organization, so one organization's SCPs can never reach another's accounts.
• StackSets auto-deployment reconciles each stack set against its own administrator's organization. Reconciling every stack set against one organization would have deployed into another organization's accounts.

Bugs found and fixed along the way

• TerminateResponsibilityTransfer cleared active_handshake_id before cloning the snapshot it then read the id back from, so the riding handshake was never cancelled and a withdrawn transfer could still be accepted.
• Accepting a TRANSFER_RESPONSIBILITY handshake left the transfer at REQUESTED with a live handshake id — two sources of truth disagreeing. It now moves with the handshake.
• resolve_handshake enrolled the target on any accepted handshake, so accepting a transfer would have enrolled the other organization's management account. Enrollment is now INVITE-only.
• Responsibility transfers were only readable from the organization storing them, so the inbound party could never see the transfer it was invited to take over. Both parties can now read it; only the source can rename or withdraw it (AccessDeniedException, not a misleading not-found).
• InviteAccountToOrganization trusted Target.Id without checking it against Target.Type, so {Type: ACCOUNT, Id: "bob@corp.com"} opened a handshake nobody could ever accept. Now InvalidInputException.

Reads that were satisfied by "an organization exists" now require membership — ListParents, ListChildren, ListTagsForResource, DescribeEffectivePolicy, DescribeResourcePolicy (which ignored the caller entirely) and the responsibility-transfer ops. With one organization these were harmless; with two they are cross-organization reads.

Persistence

Snapshot schema goes to v2, holding the registry. v1's single-organization field is still read and folded in (into_registry), so an existing snapshot keeps loading across the upgrade; it is never written again. The loader's version guard is >, not !=, so this is a true in-place upgrade.

Introspection (wire change)

GET /_fakecloud/organizations/accounts now spans every organization: each account carries its organizationId, and a new organizations array summarises each one. The flat managementAccountId/masterAccountId stay populated when exactly one organization exists — so single-organization callers are unaffected — and are null with several, rather than reporting an arbitrary pick. /_fakecloud/organizations/responsibility-transfers rows gain organizationId for the same reason.

Test plan

• cargo nextest run -p fakecloud-organizations — 160 passed, including new coverage for: two accounts each running their own organization; a member of another organization being refused; cross-organization invite/accept rejection; organization isolation of reads (ListParents/ListChildren/ListTagsForResource/DescribeResourcePolicy/DescribeEffectivePolicy); DescribeHandshake party gating; EMAIL-target invite resolution; Target.Type/Target.Id validation; the inbound side of a responsibility transfer; source-only terminate; and v1→v2 + v2 round-trip snapshot migration.
• cargo nextest run -p fakecloud-e2e --test organizations --test organizations_scp_enforcement --test organizations_handshake --test organizations_trusted_services --test organizations_lifecycle --test organizations_introspection --test organizations_persistence --test organizations_h4 --test cloudformation_stack_sets_auto_deployment --test multi_account — 54 passed, including two_accounts_each_run_their_own_organization, an end-to-end replay of the issue's repro against the real aws-sdk-organizations.
• cargo nextest run -p fakecloud-conformance --test organizations — 8 passed.
• cargo clippy --workspace --all-targets -- -D warnings — clean. gofmt, ruff, mypy, prettier, eslint — clean.

Surface sync

• SDKs (all 7) — Rust, Go, Python, TypeScript, Java, PHP, .NET carry organizationId on accounts and transfers plus the new organizations summary. Every addition is appended or defaulted, and Java/.NET keep delegating constructors, so no positional caller breaks.
• Reference docs — reference/organizations.md drops "one organization per fakecloud process" and documents the per-caller rejection, the one-organization-per-account rule and its error code; reference/introspection.md and services/organizations.md document the new response shape.
• Machine metadata — no service/op/variant counts move, so no conformance baseline, ops-index or repo-description change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EeYYZqG5anqYXR8761ZjWu

---

Summary by cubic

Fixes #2543 by replacing the process-wide single-organization state with an OrganizationsRegistry keyed by organization id. Previously one account's organization permanently locked every other account out of creating its own; now any account outside an organization can create one, and organizations never see each other.

Behavior

• CreateOrganization/DeleteOrganization and the CloudFormation provisioner reject only the caller's own membership and remove only the caller's organization.
• An account belongs to at most one organization, enforced at invite, acceptance, and join; registry-wide id minting with in-flight reservations holds the invariant across organizations.
• Handshakes resolve across organizations so an invited account can answer; SCP ceilings, AssumeRoot, and StackSets auto-deployment stay in the caller's own organization.
• Reads that previously only required "an organization exists" now require membership; responsibility-transfer reads resolve by party, with renaming source-only while REQUESTED and either party able to end an accepted transfer.
• ListHandshakesForOrganization, ListAWSServiceAccessForOrganization, ListDelegatedAdministrators, and ListDelegatedServicesForAccount admit delegated administrators through the same gate as DescribeResourcePolicy; mutations stay management-only.

Bug fixes

• One shared predicate decides who a handshake target is, used by the handshake and transfer gates and the account's own listing, which now includes handshakes the caller sent and accepts a TRANSFER_RESPONSIBILITY action filter.
• Withdrawn transfers could still be accepted, accepted ones kept a live handshake id and an end timestamp, and targets were enrolled on any accepted handshake rather than INVITE-only; a TRANSFER_RESPONSIBILITY handshake now carries the transfer type, start time, and management account/email under the transfer id and stores the id itself.
• Reserved ids count as claimed on every enrolling path — CreateOrganization, invites, acceptance, and the create-admin shortcut — and acceptance enrolls the account the party gate proved; a failed CreateAccount drops the tags it attached synchronously.
• Account addresses are unique except the GovCloud mirror sharing its owner's; the first caller wins a contested address, the failure is persisted as EMAIL_ALREADY_EXISTS on the completion tick, closed accounts release their address, and the synthetic address belongs to its id even before the account exists.
• Target resolution prefers the registered address over the synthetic decode so one address names one account; the management gate runs before address checks, and the CloudFormation provisioner resolves the stack's own organization first.
• Transfer targets are recorded as named and the party check asks the caller its own address; naming a target in the caller's own organization — by id, synthetic address, or registered email — is rejected with SOURCE_AND_TARGET_CANNOT_MATCH, and a plain member of another organization is refused while a standalone account stays valid.
• AcceptHandshake rejects an invitee who joined another organization while the invitation sat open and enrolls with a free address; the party gate runs before the state check so a bystander learns only that it is not a party; the staleness re-check also covers transfer targets.
• Duplicate-handshake detection scans INVITE handshakes only; both invite ops validate Target.Type against Target.Id and require it; only ListInboundResponsibilityTransfers honors the optional Id filter; DescribeEffectivePolicy rejects a foreign TargetId and root ids widen to 12 characters.
• A delegated-administrator grant ends with the membership it was granted to; a TRANSFER_RESPONSIBILITY handshake without a stored transfer id falls back to the transfer's ActiveHandshakeId; and DeregisterDelegatedAdministrator now names the account rather than the service principal when nothing is registered.
• Snapshot schema goes to v2 with in-place v1 migration; GET /_fakecloud/organizations/accounts spans all organizations (organizationId per account plus an organizations array) with flat managementAccountId/masterAccountId occupied only when exactly one organization exists, across all seven SDKs.

^{Written for commit 7733614. Summary will update on new commits.}