feat(identity): two provisioning settings, and the cloud and on-prem split stops being two products

[AndrejK666]

Fifth in ADR-0018's order. Stacked on #125, targeting feature/create-your-organization.

The split stops being two products

ADR-0018 §4 claimed the domain model is identical whether Studio runs as a cloud service or inside one company, and that the difference is only how a person comes by their first organization. This makes that true. Two settings, no deployment mode, no branches behind a flag:

studio-user:
  config:
    on_first_login:              # cloud: absent
      organization: "<uuid>"
      role: "member"
studio-organizations:
  config:
    self_service: false          # cloud: true

Nothing else in the model — and no authorization path — knows which of the two it is running as.

⚠️ Why auto-join is not "access derived from authentication"

This is the part worth arguing with, because ADR-0011 §1 forbids the thing it superficially resembles.

The membership is written at the one moment a person begins to exist, and it is a row:

• it can be revoked — suspending somebody in Studio without removing them from the corporate directory, which is usually what a company actually wants;
• membership.source records that it came from a first login, not from an invitation or an operator.

Access that followed the token could do neither. The deployment is making a statement — the users of this identity provider are the members of this organization — and the statement is recorded as data. §1 stands: authentication still grants nothing by itself.

The join happens on provisioning, not per request. If it ran per request, a revoked membership would come straight back and revocation would be a lie. Verified below.

on_first_login.role may not be owner: a deployment does not hand ownership to everybody who signs in. A config that says so is refused with a log rather than obeyed.

Both settings fail soft. A join that cannot be written is logged — a person who exists but has not joined is one the next request can still join, whereas failing there would leave them unable to sign in at all.

For the portal

GET /studio-organizations/v1/capabilities → { self_service }, so the no-organization screen can offer creation where it is possible and say "wait for an invitation" where it is not, instead of offering a control that answers 403.

Verified

On a stand, by running one deployment as both — the same binary, the same database, only the two settings changed:

cloud phase    capabilities → { self_service: true }
               an organization is created

on-prem phase  capabilities → { self_service: false }
               a brand-new subject's first request → member / first_login
               creation → 403 SELF_SERVICE_DISABLED — for the administrator too,
                          because this is an installation policy, not a role
               membership revoked → no memberships, and /me still answers 200
                          (the identity is untouched; only the row is gone)

That last line is the one the ADR's argument rests on, so it is tested rather than asserted.

Tests: 502/502 with a real Postgres, clippy --all-targets -- -D warnings and cargo fmt --check clean.

Not here

The portal side — a create control on the no-organization screen, and an invitations view. The backend now answers everything both need; the UI is the next piece, and it is where ADR-0018 §2 finally becomes visible to a person.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: 8a2434ae-4123-4fd7-b5c9-8522bbba4ab2

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[AndrejK666]

Folded into #132, which carries this branch's commits unchanged along with the four pieces that finish the scope. Closing this one in favour of that is safe — nothing here is lost.