remove user-secrets approach & prepare a pilot deploy

server/CLAUDE.md

@@ -67,8 +67,10 @@ Persistence below). **In deployed environments**, boot instead only *checks* the
 reachable SQL Server is required to start. Startup **fails fast**
 (`StartupSecretsGuard`) if a load-bearing secret — the DB connection strings, and in deployed environments the
 JWE + field-encryption keys — is missing or left at its committed `SET_VIA_USER_SECRETS_OR_ENV` placeholder
-(refinement-phase-5). Development supplies working dev-only crypto keys via `appsettings.Development.json`; only
-the connection string must come from user-secrets (see [RUNBOOK](../dev/post-phase/refinement/RUNBOOK.md)).
+(refinement-phase-5). **`dotnet user-secrets` is no longer used** — the `<UserSecretsId>` was removed from
+`Baya.Web.Api.csproj`, so that store is not read at all. Every value, connection strings and dev-only crypto keys
+alike, lives in `appsettings.Development.json`; the deployment's two container-specific overrides live in the root
+`docker-compose.yml` (see [DEPLOY.md](../DEPLOY.md)).
 
 ---
 
@@ -128,11 +130,10 @@ stamped by `AuditFieldInterceptor` (Persistence), not in handlers.
 **real HTTP adapter** in `Baya.Infrastructure.CrossCutting/Seams/Real/`, **config-selected** by a per-rail
 `Seams:*:Provider` selector in `AddCrossCuttingSeams` (default = the mock, so an unconfigured env is unchanged;
 a typo falls closed to the mock). Real adapters use `HttpClient` (typed via `IHttpClientFactory`) +
-`System.Text.Json` + BCL crypto — **no new NuGet packages**; credentials come from `Seams:*` (user-secrets/env,
-never committed). Swapping is a registration change; **no handler is touched**. The adapters:
+`System.Text.Json` + BCL crypto — **no new NuGet packages**; credentials come from `Seams:*` (appsettings/env). Swapping is a registration change; **no handler is touched**. The adapters:
 `KavenegarSmsSender` (`Sms:Provider=kavenegar` — **launch-critical**; when a real gateway is selected the
 Development OTP-in-logs bridge is **disabled**, so the OTP is never logged), `TelegramSmsSender`
-(`Sms:Provider=telegram` — **Development-only, broadcast, not a gateway**: it posts to the standalone
+(`Sms:Provider=telegram` — **broadcast, not a gateway**; the pre-launch demo OTP rail: it posts to the standalone
 `telegram-otp-bot/` relay, which pushes *every* code to a fixed list of Telegram chat ids, so manual testing
 beats reading OTPs out of the log. It is the **one non-mock SMS provider that keeps the OTP-capture bridge
 enabled** — see Startup wiring — and its `Seams:Sms:Telegram:ApiKey` is a user-secret, never committed),
@@ -733,9 +734,9 @@ action to `sender.Send(...)`. Full conventions are in [CONVENTIONS.md](CONVENTIO
 - Dynamic permission system: `DynamicPermissionHandler` reads `[controller]` + `[action]` route
   values and checks role claims. Always use `[controller]`/`[action]` tokens so the keys stay
   consistent (see CONVENTIONS.md §1 Routing).
-- Settings bound from `appsettings.json` → `IdentitySettings`. **JWE keys are never committed**: the
-  committed values are `SET_VIA_USER_SECRETS_OR_ENV` placeholders (real ones via user-secrets/env; Development
-  uses dev-only keys in `appsettings.Development.json`). `RequireHttpsMetadata` is **on outside Dev/Testing**
+- Settings bound from `appsettings.json` → `IdentitySettings`. The base `appsettings.json` carries
+  `SET_VIA_USER_SECRETS_OR_ENV` placeholders that `StartupSecretsGuard` rejects; the real values live in the
+  environment-specific file (`appsettings.Development.json` holds the dev-only keys the demo deployment runs on). `RequireHttpsMetadata` is **on outside Dev/Testing**
   (passed into `RegisterIdentityServices`), the access-token lifetime is `ExpirationMinutes: 60`, and
   `Issuer`/`Audience` are real (`Balinyaar`/`BalinyaarClient`) — refinement-phase-5.
 - Auth and OTP endpoints must be rate-limited (CONVENTIONS.md §11) — `request_otp`/`verify_otp` use