DESIGN.md: record the missing OIDC trustEmail field, found exercising a real second install

Found while standing up terdut-demo (Ryuvia/charts#275), a second real
TerdutServer against the same Authentik provider as production: OIDCSpec
has no trustEmail override, so a demo install copying production's OIDC
config otherwise verbatim silently runs with the wrong default for it.
Not fixed here -- recorded in §13 as a real, found gap, not a decision,
same as the mid-life teamRef note already there.

DESIGN.md

@@ -767,6 +767,21 @@ what it was, a separate install, until someone deletes it.
   integration/policy/switch to a different team in place regardless, so
   retargeting one onto a live child isn't a supported operation in v1 —
   delete and recreate the CR instead.
+- `TerdutServerSpec.OIDC` has no `trustEmail` field (nor `usernameClaim`,
+  `emailClaim`, `groupsClaim` — the "rather than being added here
+  speculatively" fields its own doc comment already names), unlike
+  `charts/terdut-server`'s own chart, which sets `oidc.trustEmail: true`
+  for the production install specifically because Authentik reports
+  `email_verified: false` and without it a user's first SSO sign-in
+  creates a second, empty account instead of linking to their existing
+  one (`terdut-server/README.md`'s own account of this). Found by
+  actually trying to stand up a second real `TerdutServer` against the
+  same Authentik provider (`terdut-demo`, `Ryuvia/charts#275`), not by
+  inspection: that install's OIDC config is otherwise a straight copy of
+  production's and runs with terdut-server's own default (`trustEmail:
+  false`) regardless, since the CRD has nowhere to put the override.
+  Worth closing if a second real OIDC install becomes routine rather than
+  a one-off exercise.
 - Gitops-managed team *membership* (see §4.2).
 - Automatic Deployment restart on upstream Postgres credential rotation.
 - Admission webhooks / CEL-only validation limits (e.g. verifying a