Tenant-level form repository for reusable process forms

[quentinovega]

Context

Process steps (subscription process, account creation process) can embed a form
in react-forms format. Today the form schema is defined inline in each
ValidationStep.Form, so the same form has to be re-created by hand for every
plan / API / process, with no single source of truth:

// daikoku/app/fr/maif/daikoku/domain/apiEntities.scala
case class Form(
    id: String,
    title: String,
    schema: Option[JsObject] = ...,
    formatter: Option[String] = "[[motivation]]".some,
    formKeysToMetadata: Option[Seq[String]] = None,
    info: Option[String] = None
) extends ValidationStep { ... }

We want a tenant-level repository of reusable form schemas, so a Form step
can either reuse an existing schema or define a new inline one — and editing a
repository schema propagates everywhere it is referenced.

Scope

• Only the schema is stored in the repository. formatter,
  formKeysToMetadata, info stay inline on the step and remain the user's
  responsibility.
• A Form step stores a reference (id) to the repository schema, not a
  copy. The raw schema is resolved from the repository at read time — this keeps
  propagation automatic and is the smallest change to the process model.

Proposal

Backend

• Add a minimal TenantForm entity — id, tenant, schema and a default
  title (nothing else) — with its JSON codec, storage and GraphQL exposure.
• Add a collection on Tenant, following the thirdPartyPaymentSettings
  pattern, e.g. formRepository: Seq[TenantForm] = Seq.empty.
• Add an optional ref: Option[String] (tenant form id) on
  ValidationStep.Form. When set, schema is resolved from the repository at
  read time; when unset, the inline schema is used (current behavior).
• Expose CRUD endpoints for the form repository (tenant admin scope).

Frontend

• Add a management UI for the form repository in the tenant admin backoffice
  (list / create / edit / delete schemas).
• In SubscriptionProcessEditor.tsx (and the account-creation process editor),
  let the user pick an existing repository schema (stores the ref) or define a
  new inline schema, while still editing formatter / info locally.

Acceptance criteria

• A tenant admin can create, edit, list and delete form schemas in a
  tenant-level repository (id, title, schema).
• When configuring a Form step, the user can reuse an existing repository
  schema (by ref) or define a new inline schema.
• Editing a repository schema is reflected in every process that
  references it, without re-editing each process.
• formatter, formKeysToMetadata and info remain editable inline on
  each step and are unaffected by the repository.
• Deleting a referenced schema is handled explicitly (blocked or clearly
  surfaced) so no step points at a missing schema.
• Existing inline Form steps keep working unchanged.
• Repository schemas are tenant-scoped (not usable across tenants).
• Backend: entity, JSON codec, storage, GraphQL and routes added and
  covered by tests.