Give three more admin surfaces back to the domains that own them

default-user-settings, notification-preferences and oidc leave AdminController.
The first two were pure pass-throughs on AdminService that did nothing but
forward and cast; the third had its SQL there for a domain that already had a
module of its own. AdminService loses SettingsService and
NotificationPreferencesService entirely.

Two things came out of the move rather than going into it.

The OIDC lockout guard now has tests. It refuses to clear the SSO config while
password login is disabled — otherwise the instance has no SSO to log in through
and no password form either — and nothing covered that branch before, because it
sat among admin tests that only exercised the happy path.

The admin e2e app had to learn about the split. It assembles AdminModule alone,
so the moved routes 404'd there while working in production; it now imports the
three domains too. That is the same failure mode the module-provider guards
catch for RPC classes, and it is worth knowing that an e2e app which builds a
subset will find it first.

Also fixes the audit route note: audit-log stays on AdminController on purpose.
AuthModule imports AuditModule, so an admin-gated controller in AuditModule
closes a cycle — the same trap the addons toggles hit.

server/src/nest/settings/settings.controller.ts

@@ -1,9 +1,14 @@
-import { Body, Controller, Get, HttpCode, HttpException, Post, Put, UseGuards } from '@nestjs/common';
+import { Body, Controller, Get, HttpCode, HttpException, Post, Put, Req, UseGuards } from '@nestjs/common';
+import type { Request } from 'express';
 import { MASKED_SETTING_VALUE } from '@trek/shared';
 import type { User } from '../../types';
 import { SettingsService } from './settings.service';
 import { SettingUpsertDto, SettingsBulkDto } from './settings.dto';
+import { AdminDefaultUserSettingsDto } from '../admin/admin.dto';
 import { JwtAuthGuard } from '../auth/jwt-auth.guard';
+import { AdminGuard } from '../auth/admin.guard';
+import { AuditService } from '../audit/audit.service';
+import { getClientIp } from '../audit/client-ip';
 import { CurrentUser } from '../auth/current-user.decorator';
 
 /**
@@ -46,3 +51,42 @@ export class SettingsController {
     }
   }
 }
+
+/**
+ * /api/admin/default-user-settings — the defaults a new account starts with.
+ *
+ * These two routes sat on AdminController and reached SettingsService through a pair
+ * of pass-through methods on AdminService that did nothing but forward. The owner is
+ * here, so the routes are too; the path and both response shapes are unchanged.
+ */
+@Controller('api/admin/default-user-settings')
+@UseGuards(JwtAuthGuard, AdminGuard)
+export class AdminDefaultUserSettingsController {
+  constructor(
+    private readonly settings: SettingsService,
+    private readonly audit: AuditService,
+  ) {}
+
+  @Get()
+  get() {
+    return this.settings.getAdminUserDefaults();
+  }
+
+  @Put()
+  update(@CurrentUser() user: User, @Body() body: AdminDefaultUserSettingsDto, @Req() req: Request) {
+    try {
+      this.settings.setAdminUserDefaults(body as unknown as Record<string, unknown>);
+      this.audit.writeAudit({
+        userId: user.id,
+        action: 'admin.default_user_settings_update',
+        ip: getClientIp(req),
+        details: body as Record<string, unknown>,
+      });
+      // Answer with the stored defaults, not the request body: the service normalises
+      // and drops unknown keys, and the admin panel renders straight from this.
+      return this.settings.getAdminUserDefaults();
+    } catch (err) {
+      throw new HttpException({ error: err instanceof Error ? err.message : String(err) }, 400);
+    }
+  }
+}