Decide on Organization entity, metadata, and assistant-creation derivation flow

[martinydeAI]

The assistant entity (tracked in #14) needs to carry metadata about:

• framework — which AI framework the assistant runs on
  (OpenWebUI today, possibly others later)
• language model — which underlying LLM the assistant uses
• organization(s) — which organisations actually use the
  assistant

In practice, both framework and language model are decided at
the organisation level (one kommune commits to a deployment of
OpenWebUI + a specific model). It would be a poor UX to ask every
user to re-type those choices every time they create a new assistant
— the data should be derivable from the user's organisation.

This points at making Organization a first-class entity with its
own metadata (name, e-mail domain(s), default framework, default
language model), with a User → Organization relation and an
Assistant ↔ Organization relation.

It also overlaps with ADR 004 (#60, PR #61), which currently uses an
env-var allow-list of e-mail domains for self-signup. Once
Organization exists, that allow-list is "the set of registered
organisations".

What the ADR needs to record

• Whether Organization is a first-class entity (yes, per the working
  assumption above — confirm).
• The entity's fields and relations:
  • name
  • e-mail domain(s) — one or many per organisation?
  • default framework
  • default language model
  • User ↔ Organization (M:1) — derived from the user's e-mail
    domain at signup
  • Assistant ↔ Organization (M:N) — multiple orgs may share an
    assistant
• The derivation flow at assistant-creation time — does the
  assistant store its own framework / language model (snapshot) or
  always read through the org (live reference)?
• How this interacts with ADR 004:
  • Does Organization replace the env-var allow-list outright, or
    coexist as a bootstrap mechanism?
  • Does the registration flow now reject e-mails whose domain isn't
    on any registered Organization?
• Migration story — how the existing User (from User login #2) gets an
  organisation backfill.

Related

• Define assistant data model #14 — Assistant data model (consumer of framework / language
  model / org link)
• Assistant catalog listing page #15, Assistant details page #20, OpenWebUI integration workflow #27 — downstream consumers (catalogue, details,
  OpenWebUI integration)
• feat: add User entity with active / domainManager / name fields #45 — User entity (gets a new organization relation)
• Decide on user registration, approval, and account-state model #60 / PR docs: add ADR 004 — user registration, approval, and account state #61 — ADR 004 (email-domain allow-list — supersedes its
  env-var mechanism once Organization lands)
• feat: anonymous self-signup with email-domain allow-list #62 — self-signup flow (allow-list source changes)

Acceptance

• ADR under docs/adr/ recording the decision.
• Implementation issues filed for: the Organization entity +
  migration, the assistant-creation derivation flow, and the
  registration switchover from env-var to Organization-backed
  allow-list.
• If the decision changes anything in ADR 004 beyond the
  already-anticipated "graduate the allow-list to a Domain
  entity" note, ADR 004 is amended or superseded accordingly.