POST /api/custom-domains now accepts a third body variant — { pattern }
without an explicit kind or type — which the resolver infers from the
pattern shape so the frontend can ship a single dynamic input field
instead of asking the user to choose between Seite / E-Mail in advance.
- pattern contains '@' → treat as kind='mail', strip the
local-part, store as mail_domain
after the same TLD / DOMAIN_RE
validation as the explicit-kind path
- pattern contains '.' (no '@') → treat as kind='web'
- neither → 400 INVALID_PATTERN with a clear
message ("Bitte eine Domain oder
Mail-Adresse eingeben")
Variant A ({ pattern, kind }) and Variant B ({ domain, type }) stay
fully supported, plus a `kind: 'auto'` keyword if a client prefers an
explicit opt-in to the auto-detect path. The display-name path is still
locked off in v1.0 — pure tokens without dots route into the same
INVALID_PATTERN response, which keeps the v1.0 guarantee intact.
Plan-limits.test.ts grew the matching test cases — auto-detect for a
domain, auto-detect for a full address (local-part stripped to mail_-
domain), auto-detect rejection for a bare token. All existing tests
keep their pass status.
a2680f6e19