Support multiple tenants under one Spacelift account

Today a Spacelift account is single-tenant: one root space, one set of account-level settings (SSO, audit trail, billing, login-policy ownership), and spaces as the only isolation boundary inside it. Spaces are excellent for team/project segregation, but they are not a hard tenant boundary, since root/account admin remains all-powerful across every space, and several controls stay account-wide.

We need the same pattern GitHub provides with Enterprise → multiple Organizations: one commercial / SSO / billing substrate, with multiple tenants underneath as first-class isolation units. Each tenant would own its own admin boundary, spaces tree, integrations, and audit delivery, without requiring a fully separate Spacelift account per regulated entity.

Analogy:

GitHub: Enterprise → Org A / Org B / Platform Org Spacelift: Account → Tenant A / Tenant B / Platform Tenant └── spaces… └── spaces… 

That would let us keep a shared paved path (modules/policies consumed across tenants) while giving each regulated entity a native isolation unit stronger than a space subtree, without the cost and duplication of N independent Spacelift accounts.

Related: we are also requesting per-space audit trail endpoints (link after posting) for the spaces-only model; multi-tenant accounts would preferably include per-tenant audit trail as part of the tenant boundary.